Я занимаюсь настройкой крупномасштабной фермы хранения, и, чтобы избежать необходимости в месячных fscks, мой план состоит в том, чтобы разделить хранилище на множество меньших файловых систем (это нормально, поскольку у меня есть хорошо разложенное дерево файлов , поэтому я могу легко смонтировать отдельные файловые системы на 1/, 2/, 3/, 4/, и т.д).
Мне трудно найти какое-либо перечисление того, что такое "разумный" размер файловой системы, чтобы время fsck оставалось таким же "разумным". Хотя я полностью осознаю, что абсолютное время для данного размера будет в значительной степени зависеть от оборудования, я не могу найти никакого описания формы кривой для времени ext3 fsck с различными размерами файловой системы и другими переменными ( занимает ли файловая система, полная файлов в одном каталоге, больше времени, чем файловая система с 10 файлами в каждом из тысяч каталогов в дереве; большие файлы против маленьких файлов; полная файловая система против пустой файловой системы и т. д.).
Есть ли у кого-нибудь ссылки на какие-либо хорошо изученные цифры по этому поводу? В противном случае любые анекдоты об этих проблемах должны, по крайней мере, помочь мне направить мои собственные эксперименты, если это потребуется.
РЕДАКТИРОВАТЬ: Чтобы уточнить: независимо от файловой системы, если что-то пойдет не так с метаданными, это нужно будет проверить. Не имеет значения, включены ли повторные проверки на основе времени или монтирования или нужны ли они, и единственная причина, по которой я запрашиваю числа, конкретно относящиеся к ext3, заключается в том, что это наиболее вероятная файловая система, которую следует выбрать. Если вам известна файловая система с особенно быстрым процессом fsck, я открыт для предложений, но он должен быть надежным вариантом (утверждения, что «файловая система X никогда не нуждается в fscking!», Будут смеяться и высмеиваться) . Я также осознаю необходимость создания резервных копий, и желание использовать fsck не заменяет резервные копии, однако просто отбрасывание файловой системы и восстановление из резервной копии, когда она дает сбой, а не fscking, кажется действительно действительно глупый компромисс.
Согласно статья Mathur et al. (стр. 29) время e2fsck линейно растет с количеством inodes в файловой системе после определенного момента. Если судить по графику, вы более эффективны с файловыми системами до 10 миллионов inode.
Помогло бы переключение на ext4 - при условии, что ваша файловая система не загружена до краев, и прирост производительности (из-за того, что не проверяются inode, отмеченные как неиспользуемые), не имеет заметного эффекта.
Я думаю, вам придется провести собственный сравнительный анализ. Быстрый поиск в 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. стоит посмотреть.