Доклад Google о файловых системах Linux

Опубликована  http://google-opensource.blogspot.com/2011/05/linux-file-systems-in-cloud-linux.html видеозапись доклада Майкла Рубина (Michael Rubin), занимающегося системами хранения данных в Google, о причинах миграции с файловой системы Ext2 на Ext4. В докладе показаны результаты исследования производительности EXT2, достоинства и недостатки различных файловых систем, доступных в Linux, причины выбора файловой системы Ext4 для использования на серверах Google.

Некоторые тезисы:

Файловая система 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% в зависимости от типа журнала). Конфигурация без журнала также продемонстрировала большую предсказуемость.

 http://www.opennet.ru/opennews/art.shtml?num=30478