Я делаю настройку для крупномасштабной фермы хранения, и чтобы избежать необходимости в fscks на протяжении месяца, я планирую разделить хранилище на множество небольших файловых систем (это нормально, так как у меня хорошо скомпонованное дерево файлов , так что я могу легко иметь отдельные файловые системы смонтированы на 1/, 2/, 3/, 4/и т.д.).
Моя трудность заключается в том, чтобы найти любое перечисление «разумного» размера для файловой системы, чтобы время fsck также было «разумным». Хотя я полностью осознаю, что абсолютное время для данного размера будет в значительной степени зависеть от аппаратного обеспечения, я не могу найти какое-либо описание формы кривой для времен ext3 fsck с различными размерами файловой системы и каковы другие переменные ( занимает ли файловая система, полная файлов в одном каталоге, дольше, чем один с 10 файлами в каждой из тысяч каталогов в дереве; большие файлы - маленькие файлы; полная файловая система - пустая файловая система и т. д.).
У кого-нибудь есть ссылки на какие-нибудь хорошо изученные цифры по этому поводу? В противном случае любые анекдоты об этих проблемах должны, по крайней мере, помочь в проведении моих собственных экспериментов, если это потребуется.
РЕДАКТИРОВАТЬ : Чтобы уточнить: независимо от файловой системы, если что-то пойдет не так с метаданными, его нужно будет проверить. Независимо от того, включены ли re-fsck на основе времени или монтирования или нет, это не имеет значения, и единственная причина, по которой я спрашиваю цифры, относящиеся исключительно к ext3, заключается в том, что это наиболее вероятная файловая система. Если вы знаете о файловой системе, которая имеет особенно быстрый процесс fsck, я открыт для предложений, но это действительно должен быть надежный вариант (утверждают, что «файловая система X никогда не нуждается в fscking!», Над ней будут смеяться и высмеивать долго) , Я также осознаю необходимость создания резервных копий, и желание использовать fsck не заменяет резервные копии, однако просто отказ от файловой системы и восстановление из резервной копии, когда она дает сбой, а не fscking, кажется действительно
Я думаю, что вам придется сделать свой собственный сравнительный анализ. Быстрый поиск в Google ничего не показал, за исключением того, что ext4 fscks намного быстрее, чем ext3.
Итак, создайте несколько разделов ext3, 100 ГБ, 200 ГБ и т. Д. До размера диска, который вы будете использовать. Затем заполните их данными. Если вы можете использовать данные, которые похожи на ваши производственные данные (файлы на каталог, размер файла и т. Д.), Тогда это будет лучше всего. Обратите внимание, что простое копирование файлов с другого устройства для резервного копирования разделов поместит их на диск идеально разложенными и дефрагментированными, и поэтому в ваших тестах будет отсутствовать много времени поиска головки диска, которое придет из-за большого количества операций записи / изменения / удаления.
Вам также нужно будет подумать о параллельных fscks. Смотрите последние пару полей в / etc / fstab. Разделы на одном физическом диске должны выполняться последовательно; несколько дисков на одном контроллере могут выполняться параллельно, но будьте осторожны, чтобы не перегружать контроллер и не замедлять их работу.
источник
http://lmgtfy.com/?q=fsck+benchmark
Похоже, что fsck в файловых системах ext4 значительно быстрее, чем в ext3, причем некоторые отчеты о ext4 fsck работают в 10 или даже больше раз быстрее, чем ext3.
две довольно интересные статьи из этого поиска:
http://thunk.org/tytso/blog/2008/08/08/fast-ext4-fsck-times/ иhttp://thunk.org/tytso/blog/2009/02/26/fast-ext4-fsck-times-revisited/
источник
есть ли какая-то причина, по которой вы не можете использовать файловую систему, которая не заставляет вас запускать fscks на основе времени или числа монтирований при перезагрузке?
(основанные на времени fscks действительно меня беспокоят - для сервера с длительным временем работы это в значительной степени гарантирует, что вам придется выполнять полный fsck всякий раз, когда вы обновляете ядро).
в любом случае, XFS является одной из файловых систем журналирования, которые не используют fsck. стоит посмотреть.
источник