Комментарии 43
Все чаще диски в разметке GPT. Стоит изучить тему.
Из ситуации с закончившимися inode ситуация почти безвыходная, но можно попробовать финты с уменьшением размера файловой системы и созданием нового диска с новой файловой системой. Благо дерево очень гибкое. Как временное решение — файл с временной файловой системой и устройство /dev/loop{n}.
Из ситуации с закончившимися inode ситуация почти безвыходная, но можно попробовать финты с уменьшением размера файловой системы и созданием нового диска с новой файловой системой. Благо дерево очень гибкое. Как временное решение — файл с временной файловой системой и устройство /dev/loop{n}.
Ещё лучше заиспользовать XFS.
периодически ловлю подвисания на большом (8x10Tb) разделе xfs при активном обращении + проверка массива md.
bugzilla.kernel.org/show_bug.cgi?id=201331
не так давно поймал потерю данных после такого фриза + ребут, было очень больно.
bugzilla.kernel.org/show_bug.cgi?id=201331
не так давно поймал потерю данных после такого фриза + ребут, было очень больно.
Альтернативы? ZFS?
> ZFS
Да, вполне. Отлично работает уже больше полугода в продакшене. 2x4Tb, зеркалирование средствами самого ZFS (миграция живого сервака md+ext4 -> zfs без физического доступа и вменяемой консоли была очень интересным развлечением). Уже подумываю о переезде этого сервера на FreeBSD :)
Да, вполне. Отлично работает уже больше полугода в продакшене. 2x4Tb, зеркалирование средствами самого ZFS (миграция живого сервака md+ext4 -> zfs без физического доступа и вменяемой консоли была очень интересным развлечением). Уже подумываю о переезде этого сервера на FreeBSD :)
И как впечатления относительно XFS? Оверхед по ОЗУ на метаданные какой? Зачем фряха понятно, это родная для неё фс, но разве на линух она была плохо портирована?
> Оверхед по ОЗУ на метаданные какой?
Есть, но это все подкручивается в обе стороны при желании. Там вообще можно много чего подтюнить.
> но разве на линух она была плохо портирована
Я лично с проблемами не сталкивался, но читал о некоторых не очень приятных багах в ZOL.
Ну и еще, в линуксах пока нельзя (ну как, читал что вроде как можно с помощью напильника, и это работает, но там такая магия, что как-то не очень хочется на проде такое городить) полностью перевести сервер на ZFS, /boot все еще на старом добром ext4.
И плюс общие впечатления некоторой костыльности и чрезмерной замороченности от настройки / на ZFS.
Есть, но это все подкручивается в обе стороны при желании. Там вообще можно много чего подтюнить.
> но разве на линух она была плохо портирована
Я лично с проблемами не сталкивался, но читал о некоторых не очень приятных багах в ZOL.
Ну и еще, в линуксах пока нельзя (ну как, читал что вроде как можно с помощью напильника, и это работает, но там такая магия, что как-то не очень хочется на проде такое городить) полностью перевести сервер на ZFS, /boot все еще на старом добром ext4.
И плюс общие впечатления некоторой костыльности и чрезмерной замороченности от настройки / на ZFS.
Причин, конечно может быть много, но в тему статьи подходит такая: подвисание происходит из-за перестроения какого-нибудь дерева:
— каталог с большим числом файлов в XFS — это дерево
— свободное место отслеживается с помощью 2х деревьев: одно упорядоченно по смещению, а второе по размеру свободных (или занятых, не помню точно) областей.
— каталог с большим числом файлов в XFS — это дерево
— свободное место отслеживается с помощью 2х деревьев: одно упорядоченно по смещению, а второе по размеру свободных (или занятых, не помню точно) областей.
Ловили подвисания на очень активно используемом массиве в пару терабайт на XFS, лечилось дефрагментацией и настройкой предвыделения места (мы открывали кучу файлов и дописывали в них рандомно — получали больше миллиона сегментов в одном файле и зависания XFS при попытке работы с таким большим деревом фрагментов в ядре)
Да, нельзя ли ответить на собеседовании «Если у вас XFS или NTFS, значит просто кончилось место»?
При этом стоит учитывать, что xfs разделы нельзя уменьшить.
Мы на файловом хранилище решали очень просто: много мелких файлов клали в zip-архив. Кроме inodes выиграли «случайно» еще несколько сотен гигов места (при упаковке «без сжатия»).
Да, поскольку файлы раздавал nginx, то пришлось к нему прикрутить модуль распаковки zip на лету.
Да, поскольку файлы раздавал nginx, то пришлось к нему прикрутить модуль распаковки zip на лету.
можно про модуль подробнее?
Спонтанно родилась статья на хабре, описал все там
habr.com/ru/company/srg/blog/462967
habr.com/ru/company/srg/blog/462967
zip по своей структуре тоже довольно сложно устроен. Интересно, есть ли варианты менее ресурсоёмкие при условии, что сжатие не нужно?
zip? В Linux? А как с правами доступа и атрибутами файлов? Они же в zip не сохраняются. И почему не loop device?
Внутри zip структура файлов хранится в этом zip? Там свой маленький inode?
структура хранится, в этом его плюс по сравнению с tar
tar хранит свою структуру архива снаружи, во внешней файловой системе? Неожиданно.
tar не хранит каталог файлов в каком-то отдельном выделенном месте, у него вообще нет этой структуры, в tar есть информация об одном файле, потом сам файл, потом опять информация, потом файл, т.е. эта информация размазана по всему архивному файлу, и ее нельзя получить разово. В этом и есть проблема.
В конце zip файла есть что-то вроде «содержания» архива — список структур с именем, размером и датами для каждого сжатого файла.
У нас все сервера виртуализированные, поэтому проще создать новый диск с новой файловой системой и перенести данные.
Длинные выводы команд лучше сокращать, например с помощью grep — сильно повысится читаемость
Извините меня, что такое ЦРС?
Можно добавить что раздел у вас на картинке начинается с сектора 1 что очень плохо. Потому что современные диски имеют физический размер серктора в 4K. А чтение по LBA не кратным физическому блоку даст пенальти по производительности. Соответственно если границы блоков файловой системы не попадут на границы физических секторов диска будет просадка производительности. Узнать размер физического сектора на диске можно с помощю «hdparm -I /dev/sda». Ну или создать раздел по смещению в 1MB от начала диска что б наверняка.
Как видно, нужная нам директория содержится в блоке с номером 579. В ней мы найдем номер нода для папки home,А почему сделано через ноды?, когда можно было бы хранить ссылку на нужный блок, т.е. вся инфа о содержимом папки была бы в блоке этой папки, и подобной проблемы бы не возникло.
Необязательно использовать dd с целью увидеть содержимое специального файла директории. Отобразить его содержимое можно было и в debugfs с помощью команды block_dump (для случая местоположения файла директории в блоке 579):
block_dump 579Увидеть эти данные в читаемом виде можно было так:
ls -l <2>Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кое-что об inode