недавно у нас произошел сбой в нашем хранилище, нам нужно fsck. Объем хранилища составляет около 1,2 Тера, и это заняло у нас более 5 часов.
Есть ли альтернативное решение для файловой системы ext3 или лучше, чем ext3? Предложения за и против приветствуются.
TQVM
Есть несколько статей LWN, которые могут быть интересны:
Здесь у вас много вариантов. Файловые системы, хотя и имеют схожее базовое использование, все ведут себя по-разному в зависимости от того, какую рабочую нагрузку вы на них возлагаете - практически наверняка, хотя один человек может клясться преимуществами, скажем, ReiserFS, другой будет отвращаться к нему.
С точки зрения предприятия две файловые системы, с которыми я наиболее знаком, - это JFS и XFS. Хотя он не очень широко используется, я поклонник JFS, поскольку он НИКОГДА меня не подводил, получил высокую производительность в различных рабочих нагрузках, очень стабилен и относительно устойчив к сбоям питания. XFS даст вам немного лучшую производительность, но он имеет значительные известные риски потери или повреждения данных в случае прерывания питания - определенно стоит использовать, если вы управляли питанием.
Земля настольных компьютеров Сейчас я использую исключительно Ext4, поскольку он НАМНОГО быстрее ext3 и вызывает меньше накладных расходов на ввод-вывод и использование процессора, что отлично подходит для продления срока службы батареи моего ноутбука :-)
Хорошие ссылки для получения дополнительной информации: http://en.wikipedia.org/wiki/Comparison_of_file_systems
Изменить: Как уже упоминалось другими, в случае ошибки файловой системы [повреждения и т. Д.] Потребуется какое-то восстановление, чтобы решить проблему. Независимо от того, автоматизировано ли это [как ZFS] или вручную [практически все остальное], вашей файловой системе потребуется время, чтобы вернуться в чистое состояние. В большинстве случаев вам придется выполнять эти операции с файловой системой, которая либо отключена, либо находится в состоянии только для чтения. Сколько времени это займет, будет варьироваться в основном в зависимости от серьезности проблемы, размера / состояния метадаты и скорости ваших дисков. Ужасным примером времени, который я пережил, было повреждение XFS, требующее полной перестройки файловой системы 12 ТБ, что заняло около 12 часов.
Я подозреваю, что вы увидите аналогичные результаты для любой файловой системы, когда вам нужно будет выполнить полную проверку файловой системы. Если у вас используется 1 000 000 inodes, не имеет значения, как они организованы, если вам нужно проверить их согласованность. В любом случае, вы коснетесь 1 000 000 файлов.
То, что значительно ускорит это, - это более быстрые диски и больше шпинделей. Если вам нужно 1,2 ТБ, вы получите значительно лучшую производительность от 8 дисков SAS по 300 ГБ в RAID 10, чем от одного диска SATA 1,2 ТБ, независимо от файловой системы. Конечно, это будет стоить вам дороже, но во что вам обойдется простой? Это по-прежнему не предотвратит ошибки файловой системы, но сократит время восстановления.
Еще нужно учитывать, сильно ли изменяются данные на отказавшем томе. Если он в основном статичен и у вас есть хорошая резервная копия, возможно, будет быстрее восстановитьmkfs объем и восстановление из резервной копии. Вы рискуете потерять последние изменения, но, опять же, вам придется сопоставить это с затратами на простой.
Я не уверен, что есть какие-либо действительно хорошие альтернативы, которые в случае повреждения файловой системы fsck не занимают много времени в файловой системе такого размера. Как правило, в Linux я предпочитаю XFS, но для любого повреждения также требуется fsck. Не уверен, что это намного быстрее, чем ext3.
Хотя это не помогает в вашей текущей ситуации, дни fsck сочтены. Новые файловые системы COW, такие как ZFS в Solaris / OpenSolaris, никогда не противоречат друг другу и не требуют fsck. Я надеюсь, что Btrfs будет аналогичен в этом отношении в Linux, когда он будет готов к производству. На данный момент лучше всего попытаться ограничить размер файловых систем ... не всегда вариант в сегодняшнем бурном росте неструктурированных данных.
Знаете ли вы, что привело к повреждению файловой системы? Если питание произошло внезапно, лучшее, что вы можете сделать, это взять ИБП.
Если вы используете Linux, я бы рекомендовал внимательно изучить btrfs.
Imo, сейчас в Linux нет файловой системы, подходящей для больших хранилищ. XFS, JFS reiser и другие имеют свой собственный набор проблем. Например, дефрагментация JFS еще не была перенесена на Linux. XFS - хороший вариант только тогда, когда вы можете быть уверены, что никогда не будет потери мощности и ваше оборудование будет абсолютно надежным. Я не уверен, что последнее предсказуемо. Reiser больше не находится в активной разработке и, к сожалению, имеет немало ошибок.
btrfs - это попытка привнести в Linux функциональность ZFS, избегая при этом некоторых конструктивных недостатков ZFS. Однако имейте в виду, что btrfs в настоящее время все еще находится в активной разработке, но на стадии созревания. Я бы пока не рекомендовал его для производственного использования, но он может стать для вас жизнеспособным способом обновления в будущем. Пока вы ждете, вы, возможно, захотите использовать ext3 / 4. Хотя они далеки от совершенства, на данный момент они являются вашим лучшим выбором для Linux.
Вы не думали о том, чтобы разделить объем на части? Затем вы можете запускать параллельные fscks (или меньше, если у вас есть чистые FS).
например. 3 тома по 400 ГБ = 1,2 ТБ. Используйте символические ссылки или измените пути к домашнему каталогу, чтобы разместить файлы в нужном месте.
Почта для этого неплохо подходит - вы не получаете очень большие файлы.