Благо, ребутом никому не мешаю, попробовал на рабочей станции новую файловую систему. Процедура от силы занимает полчаса: свернул все в тар, развернул обратно.
Итак, тех, кто вообще не понимает, о чем идет речь - шлем читать
Для остальных - мои впечатления далее. Во-первых, формат еще нестабилен по состоянию на ядро 3.2, но, как я понимаю, это в силу неуверенности в неизменности формата в будущем. Сам формат вполне работоспособен (фичи вроде растягивания и создания программного рейда я не пробовал), несмотря на то, что пишут в вики, инструмент проверки и дефрагментации диска есть. Есть очень много прикольных особенностей, особенно понравилось сжатие на лету. Архивнул хранилище на USB-диск со сжатием (сейчас есть три типа архивации и два из них (zlib и lzo) - уже в стабильном ядре), привожу пример строки монтирования:
zlib - больше сжатие, lzo - больше скорость. Учитывая неаховую скорость USB-диска, уменьшенный объем записываемых данных увеличивает скорость их записи. И, несмотря на то, что в Хранилище в большинстве случаев - архивы, со 129Гб (где-то 45 минут записи) выиграл 12Гб места по сравнению с ext4 и 2Гб в разнице между zlib и lzo в пользу первого. Т.е. для хранения данных очень даже интересная штука, хотя до сих пор не рекомендуется делать это в промышленном использовании, формат еще не стабилен. Очень радует дефрагментация, скорость просто поражает в силу того, что поиск фрагментированных файлов практически не требуется. Если фрагментированного ничего нет, дефрагментация проходит где-то за секунду. Запись на диск идет ровно, без рывков, как, например, у ext4, чем это определено - не знаю, наверное, более успешным кешированием в ext4. На десктопе даже без архивации данные заняли куда меньше места, чем они же, но на ext4. Т.е. btrfs менее избыточная fs, хотя дедупликации, как я понял, еще нет.
Теперь о дегте. Основное и окончательное, что меня добило, это то, что btrfs пока еще медленнее ext4. У меня, все же, на десктопе достаточно часто бывают параллельные пишущие задачи, а запись с компрессией проц кушает достаточно хорошо. Моего core2duo для этого не хватит и на систему я сжатие не поставил. Portage (куча мелких файликов) при этом занял чуть ли не вдвое меньше места, чем на ext4. Вроде бы все хорошо, но... Тот же хром пускается на глаз ощутимо медленнее. Mutt сообщения медленнее перечитывает. В общем, по сравнению с ext4 проигрывает, хотя в будущем обещают выигрыш, да и предпосылки к этому есть. Еще что огорчило - grub не завелся при корне в btrfs, пришлось сделать /boot в ext2. Мелочь, но неприятно.
Вывод. Явно очень перспективная fs и если бы я после перехода с reiserfs поставил бы ее сразу - остался бы. Но ext4 явно более производительная, поэтому переманился. Для USB-диска оставил. На будущее, как только сравняется производительность - перейду и с ext4, поскольку система не только более функциональная, но и надежнее. Увы, пока сроков стабилизации не называли, да и Fedora все передвигает переход своих релизов на btrfs.
Явно очень перспективная fs и если бы я после перехода с reiserfs поставил бы ее сразу - остался бы
Не уверен я, что стоит экспериментировать с файловыми системами на рабочих машинах. Насколько я понимаю, она пока что не носит статус стабильной ФС. А плюсы на рабочих станциях от ее использования по сравнению с ext4, мне кажется, довольно незначительны. Стоит ли? В качестве эксперимента - интересно. Но в качестве постоянной ФС для работы....
Интересная особенность RAID-1 в btrfs заключается в том, что одновременно копия данных лежит на двух дисках, независимо от их количества. Т.е. даже если у вас 10 дисков в зеркале, данные будут лежать только на двух из них. При увеличении количества дисков, будет увеличиваться свободное место на общем устройстве. Я не знал - промахнулся и даже баг завел.
Кстати, удаление диска из RAID-1 (я удалял третий, поскольку мне нужно 3 копии архивов) выполнялось около 4х часов в случае с моими 800Гб архивов. Ребаланс не потребовался, на него, собственно, время и тратилось, т.е. перед удалением диска, данные с него автоматом перенеслись на оставшиеся два.
Конвертнул тут себе еще один диск, забыл, что на нем тестовая база...
Работала нормально, но после очередного update (directio и COW включены)
Цитата:
ERROR at line 1:
ORA-01115: IO error reading block from file (block # )
ORA-01115: IO error reading block from file 4 (block # 152)
ORA-27085: Message 27085 not found; product=RDBMS; facility=ORA
База при этом не повредилась. Отключил, по мелочам работает... Но скорость непотребная (не больше 1Мб/сек на запись)... А вот торренты нормально. Только если COW не отключить, то получается фрагментация по ~50000 кусочков на файл в 2Гб, если отключить - 6.
По итогам "проходил мимо", т.е. в тему особо не погружался, ряд выводов.
1) Торренты на BTRFS работают ровнее и быстрее, чем на EXT4, причем, даже с nobarrier.
2) Если хотите испытать адские тормоза - положите на BTRFS образы виртуалок. Причем, даже копирование в NoCOW не спасает. Такое впечатление, что в EXT4 значительно лучше работает кеширование на запись. С учетом недостаточной обкатанности BTRFS побоялся особо ее тюнить. Разница работы не то, чтобы видна на глаз, она в разы медленнее на BTRFS. Побороть не удалось, но я вернусь еще к вопросу.
3) Фрагментация сильно меньше на BTRFS и дефрагментация проходит значительно быстрее (сужу по тем же виртуалкам и торрентам).
4) ТВ фильм с EXT4 стартует куда быстрее, чем с BTRFS.
5) Поиск по дереву с большим числом каталогов на BTRFS идет заметно быстрее и хорошо кешируется.
несмотря на проблемы с RAID5 (признанный баг), использую BTRFS в хвост и гриву, правда, без снапшотов и RAID. У меня на компе, у жены на ноуте, у меня на мобильном ноуте... Видимо, если не углубляться в фичи, вещь просто бронебойная. Увы, это не ZFS в том, что касается логики работы и целостности утилит, но вполне себе классная штука, учитывая, что конкурентов по CoW у нее среди Linux FS нет, а для десктопа, учитывая необходимость в отдельной области кеша для ZFS, так и вообще...