BTRFS. Готова ли к использованию в 16.04?

[thunderamur]

Тестирую Ubuntu 16.04, решил её поставить на новый SSD и заодно посмотреть как там дела с BTRFS, все-таки регулярно в описаниях новых ядер проскакивает инфа о различных улучшениях в этой ФС. Кроме того, она имеет специальный режим для работы с SSD.

Система после установки создает запись в fstab с опциями монтирования по умолчанию defaults, но если посмотреть как реально примонтирована ФС видно, что система знает как употреблять SSD.

Код: [Выделить]

/dev/sdb5 on / type btrfs (rw,relatime,ssd,space_cache,subvolid=257,subvol=/@)
Работает ФС теперь на удивление быстро. Я помню когда я последний раз обращался в BTRFS пару лет назад она жутко тормозила при установке пакетов в систему, сейчас этого нет!

Решил пойти дальше, использовать возможности, которые данная ФС предоставляет. А именно включить сжатие - compress=lzo.
Строка монтирования в fstab приняла вид

Код: [Выделить]

UUID=81208f4e-c199-4a62-b139-2594a42ec26a /               btrfs   compress=lzo,defaults,subvol=@ 0       1
т.е. только добавил compress=lzo, больше ничего не трогал, дабы не орать потом, что ФС сломалась, когда на деле сам её сломал.
Далее загрузился в живую сессию и сделал дефрагментацию с опцией сжатия.

Код: [Выделить]

sudo btrfs fi def -clzo -r /media/<путь до раздела btrfs>/{@,@home}
В итоге получил приличную экономию места, коэффициент сжатия корня вместе с хоумом (медиаданные на другом разделе) - 0.63. Т.е. на SSD будет меньше запись в 1.5 раза! Для медленных HDD мы получим прирост скорости. Можно было использовать другой алгоритм сжатия - zlib, но он даст выигрыш к lzo результату ещё порядка 20%, но при этом в некоторых случаях будет в разы (!) больше нагружать ЦПУ, не зря разработчики предлагают по умолчанию быстрый алгоритм lzo.

Вот такая история успеха. Призываю всех кому интересно опробовать работу BTRFS на свежих системах 15.10 или как я 16.04 alpha и рассказать о результатах на своем железе.

Cравнение производительности BTRFS и EXT4 на HDD в Ubuntu 16.04 alpha
BTRFS vs EXT4 на слабом ноуте (Intel Bay-Trail, Celeron N2830)

[alsoijw]

Теперь хотелось бы посмотреть на её недостатки и сравнить с ext4.

[thunderamur]

alsoijw,
Раньше их было 2, стабильность и производительность. С производительностью сейчас проблем не вижу, хотя хорошо бы попробовать на система установленной на HDD. По стабильности раньше были сообщения о проблемах, но половина из них от неумелого тюнинга, однако траблы имели место быть. Сейчас же пока ничего не скажу, только 2-й день использую как основную, посмотрим.
Пользователь решил продолжить мысль 13 Ноября 2015, 14:33:10:alsoijw,
Блин, пойду тестить на HDD, самому интересно.

[alsoijw]

thunderamur, у тебя корень и ещё /media/<путь до раздела btrfs> на btrfs? Интересно, где-то через месяц что будет из себя представлять.

[AnrDaemon]

В итоге получил приличную экономию места, коэффициент сжатия корня вместе с хоумом (медиаданные на другом разделе) - 0.63. Т.е. на SSD будет меньше запись в 1.5 раза!

А вот это не совсем верно. Единичная запись да. А вот ПЕРЕзапись будет размывать эту цифру, и тем больше, чем лучше данные сжимаются.

[thunderamur]

Про нагрузку на ЦПУ прогнал неправильно посмотрел top. Реально при повторной конвертации когда данные в кэше zlib нагружает Haswell i5 до 100% в некоторые моменты, lzo - до 30%.

Сейчас подробный отчет по тестированию btrfs vs ext4 на hdd сделаю.

AnrDaemon,
Блин, точно BTRFS же copy-on-write.
Только я не понял этого

тем больше, чем лучше данные сжимаются

Если данные не сжимаются пишется при изменении 15 мб, сжимаются - 10 мб. Т.е. при сжатии пишется меньше. Т.е. лучше с ним, ежели btrfs.
Другое дело, что ext4 в этом случае, если изменение небольшое записала бы только его.

[AnrDaemon]

Скажем, ты изменил 4кБ данных в файле. В сжатом виде эти 4кБ повлияли на 8кБ хранимого объёма... Или больше...
Вообще, я уже три года как отказался от сжатия. До того использовал сжатие на уровне ФС на протяжении десяти лет. С лишним.

[thunderamur]

AnrDaemon,
Я думал не так. При copy-on-write файл переписывается целиком. Я изменил 4 кб в файле весом 4 мб, все 4 мб переписываются. Но, при использовании сжатия, на диск пишутся только 2.5 мб. Разве не так для btrfs?
Пользователь решил продолжить мысль 13 Ноября 2015, 19:45:05:Отчет о тестировании решил выделить в отдельную тему, уж больно много времени потрачено и объем достаточный.

Cравнение производительности BTRFS и EXT4 на HDD в Ubuntu 16.04 alpha

[Lifewalker]

При copy-on-write файл переписывается целиком.

Нет. Переписывается изменённая часть файла.

[thunderamur]

Lifewalker,
Ухты, давно тебя не видел! Стоило только написать BTRFS и вуаля)

Спасибо за инфу, а то я аж запереживал, как же такую ФС на SSD использовать.
Сам как считаешь, для SSD что лучше?
Пользователь решил продолжить мысль 13 Ноября 2015, 20:22:19:Lifewalker,
И ещё поясни за это

Скажем, ты изменил 4кБ данных в файле. В сжатом виде эти 4кБ повлияли на 8кБ хранимого объёма... Или больше...

А то я не могу понять, а AnrDaemon запарился мне объяснять.

[Lifewalker]

Сам как считаешь, для SSD что лучше?

Не знаю. У меня сейчас NFTS в качестве рабочей

И ещё поясни за это

Скажем, ты изменил 4кБ данных в файле. В сжатом виде эти 4кБ повлияли на 8кБ хранимого объёма... Или больше...

А то я не могу понять, а AnrDaemon запарился мне объяснять.

ЕМНИП, BTRFS всё хранит в листьях деревьев. Размер оных листьев задаётся при форматировании. Мне не известно, как именно реализовано сжатие, может там листья жмут, а может как-то иначе. Следовательно, никаких внятных комментариев дать не могу. Можно лишь предположить, что при изменении 1 байта, максимальный размер перезаписываемого куска не будет превышать размера листа (16К по дефолту, макс. 64К)

[volandku]

Haswell i5 до 100% в некоторые моменты, lzo - до 30%.

Это быстрый (десктопный) i5 или медленный мобильный?

[AnrDaemon]

Смысл жать листья нет - ну сожмёшь ты, например, кластер, будет реальных данных не 4к а 2,7к… Физически эти данные всё равно не могут быть записаны на объём меньше кластера.
До тех пор, пока отношение объёма изменённой информации к объёму перезаписываемой информации не превышает единицы хранения, разницы нет, что сжимать, что как.
На SSD можно много интересных дополнительных вещей придумать, но идея остаётся той же. Вероятно, твоя формула всё ещё будет верной для файлов результирующим объёмом меньше страницы флеш-накопителя. Но. Не забывай, что некоторые SSD сами по себе уже реализуют сжатие на "аппаратном" уровне.

[Lifewalker]

Однако, давайте помнить, что "практика - критерий истины". Практика говорит нам, что сжатие работает - это раз; место на диске экономится - это два; удельная цена "твердотельного" мегабайта в разы больше "механического" - это три. В итоге сжатие полезно тем, что позволяет высвободить вполне реальные гигабайты, которых немного и за которые заплачено много денег
Вывод: сжатию быть.

[victor00000]

удалить в файл test.txt на ?est.txt как быстро,
а BTRFS очистить до байти в файл и размер.
не правду?