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