Немного лирики, как всегда.
В эпоху big data вопрос резервных копий остаётся актуален и стоит остро как никогда. Это и объёмы данных и вопрос сроков работ по резервированию и дополнительно вопрос по хранению и сохранению данных. Уже довольно длительное время на рынке присутствуют хранилища огромной ёмкости, в данном случае идёт речь о классических стораджах на дисковых или ssd накопителях. Аппаратные резервы обыкновенных полок/корзин далеко не безграничны, а возможности скромны, особенно когда дело доходит до восстановления данных, например, с 5-го или 6-го рэйда дисках эдак на 10.
В своё время Sun Microsystems, ныне приобретённая Oracle-ом, начала разрабатывать ФС ZFS. Изначально эта фс планировалась именно для хранилищ, в неё встроена система управления томами. Эта система умеет Raid-0 Raid-1 Raid-Z и Raid-Z2 (аналоги 5-го и 6-го рэйдов). Также для повышения быстродействия в ZFS встроен свой мех-м кэширования метаданных и данных, 2-х уровневый: первый уровень - кэширование в ОЗУ и второй уровень - это кэширование основного хранилища в дополнительных ssd-устройствах.
Лавры ZFS не давали покоя инженерам из Oracle, кроме того, ZFS лицензируется под CDDL, которая не совместима с GPLv2, по которой распространяется ядро Linux, то есть портирование этой фс под linux и вынесение кода в mainline невозможно. В результате были начаты работы по созданию ФС BTRFS. Собственно, эта файловая система является, скажем так, прямым конкурентом ZFS. Однако, в технологическом плане ZFS более развита: btrfs не умеет шифровать данные, мех-м кэширования не столь развит, дедупликация пока что в процессе реализации, но возможна, правда только с пинка от спец-утилитой, которой оно и производится.
Обе этих системы способны, конечно, на бОльшее, за обозором фич - добро пожаловать в википедию. Тут я хотел бы рассказать о некоторых моментах практического применения этих фс.
BTRFS. Её я установил на рабочую машинку. Наблюдения оказались несколько обескураживающими. Эта система крайне медленно работает с метаданными - например удаление файлов происходит со скоростью 2-3 файла в секунду. Ядро свежее - 3.12.17. На 3.10.37 ситуация аналогичная. Вопросов к (сохранению) целостности данных у меня нет: система несколько раз отключалась по питанию, в том числе и в процессе записи данных на файловую систему - фс отработала на удивление аккуратно.
ZFS. Здесь ситуация была другая: Эту ФС использовали под большое хранилище на 6-м рэйде. Это HP ProLiant Dl180 с корзинкой на 24 диска, с контроллером p411. Надо отметить, что в данном конкретном случае 411-е контроллеры работают не очень хорошо - они иногда отваливаются. Это, можно сказать, вызов файловой системе ZFS - проверка на вшивость механизма самовосстановления. ОС FreeBSD 8.4 и zpool v28. Характерная особенность - регулярная деградация производительности - скорость записи внезапно падает со 190-197 мегабайт в секунду до 10-20 мегабайт в секунду, всяческие скрабы и проверки дисков результата не дают. Лечится только разрушением всех пулов и фс и созданием фс и пулов заново. Ну и несколько раз были более серьёзные потери - неустранимые развалы фс после внезапной перезагрузки ОС из-за сбоя контроллера.
Ну и общая черта у этих файловых систем тоже есть - пока идут технические работы (ребаланс, скраб или что-то ещё похожего содержания) файловая система почти заморожена - любые запросы к файлам, особенно stat()-запросы эпично тормозят, тот же stat() выполняется минут по 10.
Как-то в новостях мелькали статьи, что, например, фейсбук пробует пустить btrfs в продакшн, но вероятно имеется в виду как раз системы бэкапа чего-то-там, а не, например, основная фс баз данных, с которой идёт работа боевых систем.
Что касается ZFS, то она вполне рабочая, но с небольшой оговоркой - zpool необходимо размещать непосредственно на диски и собирать их в массивы силами zfs - тогда оно по идее работает более-менее сносно, однако и тут есть заковырка - zfs любит манипулировать самими устройствами, а если диск вынуть, то например во фре изменится порядок наименования дисков, эту проблему частично решает geom raid (http://habrahabr.ru/post/77722/). В солярке наименование дисков идёт в соответствии с их логическим расположением в системе напр. /dev/c1t1d4p8 имеется в виду, что устройство висит на первом контроллере, является таргетом 1, диском 4 и разделом 8, соответственно, таких детских проблем, как на фре, на соляре нет. Если ZFS класть на аппаратный рэйд, то возможны различные спецэффекты, вроде тех, что я описывал. Далее, есть ещё один тонкий момент - ZFS очень активно использует кэширование данных и если есть хоть малейшее сомнение в надёжности питания сервера или по поводу стабильности ПО, размещённого на нём, то следует отключить кэширование данных, т.к. в случае внезапного выключения питания восстановление фс займёт заметно долгий промежуток времени, это тебе не ext4fs, которы раз и прочекал терабайт на несколько минут. ZFS терабайты скрабит часами, а десятки терабайт - сутками и в это время скорость чтения с проверяемой фс очень удручает. У ZFS есть абсолютно чёткая граница между "быстро" и "надёжно": либо быстро, либо надёжно. Компромиссов нет и, скорее всего, не будет в обозримом будущем, и не надо заниматься самообманом.
И, да, отдельным пунктом стоит отметить, что zfs умеет пользоваться для кэширования ssd-накопителями, и если есть возможность обеспечить такой кэш, то его лучше обеспечить - это крайне благотворно скажется на производительности фс, а если ssd-кэш будет ~10%+, то можно включить secondary cache и для данных. Если ssd-кэша нет, то secondary cache луше отключать в целях повышения производительности фс и снижения нагрузки на cpu.
Вроде как всё.