Файловая система Linux

Существует несколько статей LWN, которые могли бы представлять интерес:

• Много поверхностей fsck
• Файловые системы: chunkfs и reiser4
• Что когда-нибудь происходило с chunkfs?

Я подозреваю, что Вы собираетесь видеть подобные результаты для любой файловой системы, когда необходимо осуществить полную проверку файловой системы. Если у Вас есть 1 000 000 inodes используемых, действительно не имеет значения, как они организованы, если необходимо проверить непротиворечивость всех их. Любым путем Вы сокращаете его, Вы собираетесь быть касанием 1 000 000 файлов.

Вещами, которые значительно ускорят это, являются более быстрые диски и больше шпинделей. При необходимости в 1,2 ТБ Вы получите значительно лучшую производительность из 8× диски SAS на 300 ГБ в RAID 10, чем Вы будете из единственного диска SATA на 1,2 ТБ, независимого от файловой системы. Несомненно, это будет стоить Вам больше, но чего Ваше время простоя стоит Вам? Это все еще не предотвратит ошибки файловой системы, но это уменьшит время восстановления.

Что-то еще для рассмотрения - изменяются ли данные по неудавшемуся объему очень. Если это главным образом статично, и у Вас есть хорошее резервное копирование, это может быть быстрее к пере -mkfs объем и восстановление от резервного копирования. Вы рискуете терять недавние изменения, но снова, необходимо взвесить это против стоимости времени простоя.

У Вас есть много опций здесь. Файловые системы, хотя имея подобное основное использование, все ведут себя по-другому зависящий, какую рабочую нагрузку Вы бросаете в них - практически уверенность, которые, в то время как один человек может клясться преимуществами, говорят, что ReiserFS другой будет не желающий она.

С точки зрения предприятия этими двумя файловыми системами, с которыми я являюсь самым знакомым, является JFS & XFS. Хотя не очень широко используемый я - поклонник JFS как его НИКОГДА не подводимый меня, полученный хороший к высокой производительности во множестве рабочих нагрузок, очень стабильных, и относительно терпим к сбоям питания. XFS даст Вам немного лучшую производительность, но это действительно имеет значительные известные риски потери данных или повреждения, если питание прервано - определенно стоящий использования при управлении питанием.

Настольная земля я теперь использую Ext4 исключительно в качестве НАМНОГО быстрее, чем ext3 и вызываю меньше i/o наверху и использование CPU, которое является большим для расширения моей жизни аккумулятора для ноутбука :-)

Хорошие ссылки для большего количества информации: http://en.wikipedia.org/wiki/Comparison_of_file_systems

Править: Как другие также упомянули, в случае ошибки файловой системы [повреждения и т.д.], некоторое восстановление оказывается перед необходимостью происходить для решения проблемы. Автоматизировано ли это [как ZFS] или руководство [фактически все остальное], это займет время для Вашей файловой системы для возвращения в чистое состояние. Большую часть времени Вы оказываетесь перед необходимостью делать эти операции с файловой системой, или размонтированной или в состоянии только для чтения. Сколько времени это взятия собирается варьироваться главным образом в зависимости от серьезности проблемы, размер / состояние метадаты и скорость Ваших дисков. Ужасным примером времени, которым я был через, было повреждение XFS, требующее, чтобы полная файловая система на 12 ТБ восстановила, который занял приблизительно 12 часов для завершения.

Я не уверен, что существуют любые очень хорошие альтернативы, что в случае повреждения файловой системы fsck не занимает много времени в файловой системе тот размер. XFS обычно является моей предпочтительной файловой системой на Linux, но любое повреждение на нем также требует fsck. Я не уверен, что это - это намного быстрее, чем ext3.

В то время как это не помогает с Вашей текущей ситуацией, дни fsck сочтены. Более новые файловые системы COW, такие как ZFS на Solaris/OpenSolaris, никогда не непоследовательны и не требуют fsck. Я надеюсь, что Btrfs будет подобен в том отношении на Linux, после того как это - готовое производство. На данный момент лучшая вещь сделать попытаться ограничить размер файловых систем... не всегда опция в сегодняшнем взрыве неструктурированных данных.

Вы знаете то, что вызвало повреждение файловой системы для начала? Если это было внезапно потерянный питания затем лучшая вещь, можно сделать, получают UPS.

Вы рассмотрели разделение Вашего объема? Затем можно идти параллельно fscks (или меньше, если у Вас есть некоторый чистый FSS).

например, объемы 3 x 400 ГБ = 1.2 ТБ. Используйте символьные ссылки или измените пути homedir, для помещения файлов в правильное пятно.

Почта довольно хороша для этого - Вы не получаете очень большие файлы.

Если вы используете Linux, я бы на самом деле рекомендую внимательно изучить btrfs.

Imo, сейчас в Linux нет файловой системы, подходящей для больших хранилищ. XFS, JFS reiser и другие имеют свой собственный набор проблем. Например, дефрагментация JFS еще не была перенесена на Linux. XFS - хороший вариант только тогда, когда вы можете быть уверены, что никогда не будет потери мощности и ваше оборудование будет абсолютно надежным. Я не уверен, что последнее предсказуемо. На самом деле Reiser больше не находится в активной разработке и, к сожалению, имеет немало ошибок.

btrfs - это попытка привнести в Linux функциональность ZFS, избегая при этом некоторых конструктивных недостатков ZFS. Имейте в виду, что btrfs в настоящее время все еще находится в стадии активной разработки, но находится на стадии развития. Я бы пока не рекомендовал его для производственного использования, но он может стать для вас жизнеспособным способом обновления в будущем. Пока вы ждете, вы, возможно, захотите использовать ext3 / 4. Хотя они далеки от совершенства, я сейчас считаю, что это ваш лучший выбор для Linux.