Выбор ФС

Материал из LORWiki
Перейти к навигацииПерейти к поиску

Совет

Написанное ниже является лишь перечислением некоторых особенностей файловых систем и не претендует на их объективную оценку

На самом деле особого прироста от смены ФС нет, все упирается в производительность самого жесткого диска. Опять же, все зависит от того, для каких задач будет использоваться тот или иной раздел диска.

В первую очередь рекомендуется посмотреть в сторону ext3, как самой проверенной и ранее используемой почти во всех дистрибутивах по умолчанию. Сейчас стандарт de facto — ext4.

Для /home достаточно любой. Важные данные? Просто включайте журналирование. Если хотите работать с разделом под Windows, предпочтительнее ext3.

Для корневого раздела: ext4, reiser3. Причина: быстрая работа с множеством мелких файлов.

Недостатки ФС[править]

  • reiser4 — по прошествии периода времени начинается жуткая фрагментация (по сообщениям разных пользователей с лора);
  • JFS — со временем (полгода-год активного использования торрентов) растёт фрагментация. Нет возможности уменьшить размер ФС, её можно только увеличивать;
  • XFS — нет возможности уменьшить размер ФС, её можно только увеличивать. Есть ненулевая вероятность потерять содержимое открытых файлов при некорректном отмонтировании/пропадании питания;
  • ext3 — число inode (максимальное число файлов) задается при форматировании, может привести к ситуации, когда место есть, а файл создать нельзя (когда очень много файлов);
  • btrfs — начиная с ядра версии 2.6.31 разработчики собираются делать только обратно-совместимые изменения в формате данных на диске, но, во-первых, никто не знает наверняка, во-вторых, ФС все еще остается экспериментальной;
  • все упомянутые ФС, кроме reiser3 и reiser4, имеют ограничение на длину имени файла в 255 байт, что может создать неудобства, особенно при использовании UTF-8 (но, так как в VFS есть ограничение на 255 байт, это преимущество никак не проявляется).

Преимущества ФС[править]

  • XFS — быстрое восстановление после потери питания, наличие дефрагментатора, эффективная работа с большими файлами;
  • JFS — использует меньше процессорного времени (тестировались ext3, reiser, xfs, jfs).

Ссылки[править]

  1. reiser4.
  2. О ext4.
  3. Сравнение ФС.
  4. http://www.debian-administration.org/articles/388.

Доклад Google о файловых системах Linux[править]

   Файловая система Ext2 очень надежна, но имеет проблемы с производительностью при высокой интенсивности ввода/вывода. Из всех дисковых операций
   40% было связано с обработкой мета-данных и только 60% с самими данными (после перехода на Ext4 это соотношение удалось свести к 4%
   для мета-данных и 96% для данных, общая производительность при этом возросла, в зависимости от областей применения, в полтора-два раза).
   При высокой нагрузке удаление 8 Мб файла иногда длилось до 800 секунд, наблюдались проблемы с фрагментацией. Как вариант решения проблемы все
   мета-данные можно было кэшировать, но это потребовало бы больших затрат оперативной памяти. Еще один недостаток Ext2 - очень долгое выполнение
   восстановления при помощи fsck - для диска 1 Тб восстановление занимало 85 минут;
   Ext3 - проблемы с долгим выполнение fsck решены за счет поддержки журналирования, но производительность осталась на уровне Ext2.
   Дополнительные плюсы - простота управления и лёгкость миграции с Ext2;
   Ext4 - кроме унаследованных у Ext3 плюсов в Ext4 частично решены проблемы с производительностью. Производительность не самая высокая среди
   доступных ФС, но вполне достаточная;
   В Btrfs реализованы очень интересные возможности, но код еще не готов для промышленного применения;
   XFS - отличная производительность, но большая усложнённость реализации;
   ZFS - отличная производительность, высокая надежность и богатые возможности с одной стороны, но с другой стороны несовместимая с GPL лицензия
   на код;
   ReiserFS и JFS не рассматривались в Google как варианты для миграции из-за недостаточной поддержки кодовой базы;
   В Google не используют журналирование - потери производительности оказались слишком большими (накладные расходы понизили производительность на
   23%-33% в зависимости от типа журнала). Конфигурация без журнала также продемонстрировала большую предсказуемость.