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

[AnrDaemon]

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

Да, всё верно. И тем не менее смысла в сжатии нет никакого.

[Lifewalker]

AnrDaemon, давайте определимся с постановкой вопроса: не смотря на приведённые и принятые вами доводы в сжатии нет никакого смысла вообще или сжатие не имеет смысла использовать на вашем компьютере с вашими задачами? Иными словами, отказ от сжатия - это объективная необходимость или ваши личные заморочки?

[AnrDaemon]

Сжатие не даёт никакого преимущества, кроме морального удовлетворения.
Файлы сохраняются медленнее, открываются медленнее. Причём сохраняются тем медленнее, чем меньше информации актуально изменяется. Поскольку даже на один изменённый байт надо пережать весь кластер целиком.
Выигрыш в хранении не стоит потерь в скорости работы. Иначе не было смысла брать SSD вообще, IMO.

[Lifewalker]

Сжатие не даёт никакого преимущества, кроме морального удовлетворения.

Тогда непонятно, зачем вы соглашались с моими доводами? Вы же сами писали:

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

Да, всё верно.

[AnrDaemon]

Ну, как же не согласиться с верным утверждением?…
Даже если оно выдрано из контекста.

[Lifewalker]

AnrDaemon, короче, если факты противоречат моим убеждениям, то факты в топку

[AnrDaemon]

Забавная у вас жизненная позиция.

[Lifewalker]

AnrDaemon, фраза "если факты противоречат моим убеждениям, то факты в топку" являлась намёком на известную цитату.
Вы имеете мнение и вам безразлично как это мнение соотностися с фактами. Используйте что хотите, только в будущем, пожалуйста, как-то согласуйте свою позицию с реальностью.

[alsoijw]

Смысл жать листья нет - ну сожмёшь ты, например, кластер, будет реальных данных не 4к а 2,7к… Физически эти данные всё равно не могут быть записаны на объём меньше кластера.

Если взять данные больше 4 Кб? Или у тебя абсолютно все файлы меньше размера кластера?

[AnrDaemon]

Цифры я приводил для примера.
Страницы на SSD больше 4к. Сколько именно, надо смотреть спеки на использованную в диске память.

[thunderamur]

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

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

Я на десктопе тестил.
Пользователь решил продолжить мысль [time]14 Ноябрь 2015, 19:29:20[/time]:

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

Ну выходит это актуально только для файлов больше размера кластера, однако, я где-то читал про такую фичу, как "сжатие хвостов", когда как раз свободное место в кластере тоже использовалось, ЕМНИП, это как раз про btrfs было (но не утверждаю, давно читал и могу ошибаться).
Кроме того. df -h, теперь правильно показывает размер btrfs, используя btrfs fi df -h. После сжатия мы видим, что использование диска уменьшилось, т.к. эта команда показывает именно использование ФС, а не суммированный размер файлов.
Да, некоторые SSD сжимают, вроде старичка Sandforce SF-2281 (на моем OCZ Vertex 3 120 как раз он), но насколько я знаю, сейчас это не так популярно среди контроллеров. Кроме того, то, что сжимает контроллер, ФС не видит и если не сжатый файл занимает 10 ГБ, то так и будет показано использование ФС несмотря на то, что на диске после сжатия контроллером всего 5 ГБ записано.
Пользователь решил продолжить мысль [time]14 Ноябрь 2015, 19:33:07[/time]:

Сжатие не даёт никакого преимущества, кроме морального удовлетворения.
Файлы сохраняются медленнее, открываются медленнее. Причём сохраняются тем медленнее, чем меньше информации актуально изменяется. Поскольку даже на один изменённый байт надо пережать весь кластер целиком.
Выигрыш в хранении не стоит потерь в скорости работы. Иначе не было смысла брать SSD вообще, IMO.

А как же те результаты которые я получил при тестировании на HDD?
ОС на BTRFS без сжатия загружается 17 секунд, со сжатием - 14.

Я не оспариваю достоверность утверждения, что производительность маленькая, при работе с маленькими объемами информации. Но ведь нам нужна производительность при работе с большими, т.к. при работе с маленькими все итак и сяк происходит очень быстро и нам не приходится ждать.
Пользователь решил продолжить мысль [time]14 Ноябрь 2015, 19:36:43[/time]:

Цифры я приводил для примера.
Страницы на SSD больше 4к. Сколько именно, надо смотреть спеки на использованную в диске память.

Страницы на SSD большие, да. Но при этом я получил экономию адресного пространства порядка 35% на чистой системе что на HDD, что на SSD. А как известно в ОС много мелких файлов. Наверное как-то хитро реализована работа с листьями в BTRFS.
Пользователь решил продолжить мысль [time]14 Ноябрь 2015, 19:38:32[/time]:А вот и проблемы - стабильность.
Пользователь решил продолжить мысль 14 Ноября 2015, 13:34:27:Проблемы уже нет, просто для BTRFS нужно чуть больше места в начале диска, чем для EXT4. Так что пока все хорошо.

[nefelim4ag]

значит BTRFS:
Cжимаются только данные, при этом блоками до 128 кб, если файл 132 кб, то отдельно будет сжато первые 128 кб и отдельно оставшиеся 4 кб
При этом если после сжатия, данных не стало меньше, они не будут сжаты (при использовании compress-force будут)

Любые данные, которые помещаются в NodeSize будут по возможности хранится вместе с метаданными, это и есть реализация Tail packing на btrfs, она не умеет хранить 2 файла по 1 байту, в 1 секторе, просто она их распихает по метаданным
Raizer4 умеет

Сжатие даёт таки профит, на HDD т.к. время считывания как правило превышает время, которое требуется процу на распаковку данных, в результате можно получать очень хороших прирост производительности
Для Дедубликации аналогично, но нужно чтобы посередине был большой кеш SSD или много свободной оперативы

[victor00000]

nefelim4ag,
сжатия даёт и удалить файл всю сжатия даёт?

[anton666]

Что то не совсем понятно каков результат? Точнее рекомендации, стоит ли использовать BTRFS в связки с SSD и использовать ли в этом случае сжатие? Хотелось бы больше цифр... Не хватает сравнений. Чем конкретно BTRFS лучше для SSD, в сравнении например с NTFS, будет ли реальный прирост в скорости?
Сжатия на сколько я понял имеет смысл использовать в уже заполненных под завязку носителях в ущерб скорости, а может быть и нет все завесит от ЦП так как при сжатии на его плече ложится дополнительная нагрузка...

[thunderamur]

anton666,
возьми потести сам и расскажи о своих выводах.