BTRFS на десктопе и волнующие вопросы

Ну прям аналога LVM (как менеджера томов, которые видны в системе как блочные устройства) из btrfs не получится, потому что подтома btrfs не могут быть блочными устройствами (как LV в LVM или ZVOL в ZFS). А не любят их не из-за того, что нафакапить легче, а из-за того, что это ломает так любимый народом Unix-way. :)

Бедненький, для управления ФС ему приходится ставить пакет ${FSNAME}-progs. :( Или для какого-нибудь LVM у тебя тоже рука отсохнет поставить пакет с утилитами, которые являются частью* проекта?

* — btrfsmaintenance пока не входит в основной проект btrfs, это да.

btrfs сама выбирает, какой алгоритм сжатия использовать?

Она сама выбирает, стоит ли сжимать конкретный блок или нет. А два алгоритма сжатия у меня из-за того, что создавал и первое время использовал FS с опцией compress=lzo, а когда в ядре появился (и стабилизировался) zstd — перешёл на compress=zstd. Те блоки, что с того момента до сих пор не перезаписались, так и используют lzo.

Вообще, можно было пережать всё (командой btrfs fi defrag -czstd /), но мне лень. :)

ext4 не подходит для хранения, там нету контроля целостности.

Нужно зачем?

Затем, чтобы иметь возможность откатить данные на предыдущее состояние в случае повреждения.

Почему тебя волнует то, зачем это нужно мне?)

Купи диск на четыре тера, если мало то купи два.

В этом нет необходимости. Я столько данных не держу.

какую-нибудь FUSE-прослойку сжимающую данные

Мне не требуется сжимать все данные.

Да, это еще одна причина выбора сабжа.

Я надеюсь, здесь есть эксперты, которые смогут объяснить русским языком

Их вон выше в треде было полно.

От себя добавлю - юзер ext4 а до этого ext3. Пару месяцев назад под корень nixos, вместо использовавшегося до этого ext4-lvm2-luks, выделил просто btrfs. Из опций монтирования «discard» и «compress=lzo». Само устройство ssd в ноутбуке. Задействование снапшотов и прочих плюшек не было т.е. дальнейшая эксплуатция просто периодическое добавление/удаление кучи чаще мелких файлов. Пока что никаких проблем не видел.

пережать всё

С учётом того, что под lzo 14M, можно забить/забыть.

Да, был пьян или туп. Спасибо.

В RHEL/Centos сломан ядерный драйвер

Да они вообще против этой ФС топят: заколебались бэкпортить походу. И даже объявляли её устаревшей и прекращали поддержку совсем.

Да они вообще против этой ФС топят: заколебались бэкпортить походу. И даже объявляли её устаревшей и прекращали поддержку совсем.

ясень пень - пользователи RHEL не хотят платить деньги за ущербные продукты.

Откуда эта статистика?

Вообще я слабо представляю что такой нужно хранить чтобы оно хорошо сжималось и при этом весило действительно много
действительно много

Шесть гигов экономии это «действительно много»? Или у тебя таких корней сотня на диске?

Почему тебя волнует то, зачем это нужно мне?)

Ты пишешь что тебе нужно экономить место, и сразу после этого пишешь что CoW это то что нужно. У меня появилось подозрение что ты упоротый.
Если объяснишь в чём состоит твой кейс то будет проще объяснить тебе что ты поехавший посоветовать тебе подходящее решение

В этом нет необходимости. Я столько данных не держу.

Так нафига их сжимать?

Ну прям аналога LVM (как менеджера томов, которые видны в системе как блочные устройства) из btrfs не получится, потому что подтома btrfs не могут быть блочными устройствами (как LV в LVM или ZVOL в ZFS).

И да, всё-таки почему «гетто-zvol» из образов в loopback будут как-то качественно медленнее zvol в ZFS?

(Качественно — т. е. помимо обычной разницы в производительности между zfs и btrfs)

compsize.

У меня появилось подозрение что ты упоротый.

А почему бы и нет.

Если объяснишь в чём состоит твой кейс

Обычный кейс, захотелось потыкать CoW, сжатие и снапшоты. Если всё пройдет гладко, оставлю сабж на постоянку. Почему бы не использовать сабж на хомячковом десктопе, тем более что в линуксах никто не запрещает использовать другую ФС/выбирать компоненты системы, чего не скажешь про эмулятор ОС от некрософта.

С моего домашнего/рабочего ноутбука. :)

Если ты про инструмент — утилита compsize.

Так нафига их сжимать?

То есть, нафига мне сжимать 100ГБ данных?

Про инструмент, да. Уже ответили, а потом я понял, что оно у меня уже установлено и (судя по history) я им даже когда-то пользовался.

32% от исходного объёма это, я считаю, отлично. Уверен, что и в хомяке бы нашлось много хорошо сжимаемых данных, но там у меня XFS, потому что захотелось поэкспериментировать (у меня в хомяке живут образы дисков VM, а им CoW ни к чему, но можно было бы просто сделать chattr +C ~/path/to/vms, да).

Честно скажу — не сравнивал (ни разу не использовал loopback на btrfs). Виртуалки с ZVOL на машине с Illumos работали так же быстро, как работало чтение/запись на обычные тома из хост-ОС. А про loopback в btrfs только слышал, что swap на таких лучше не делать, потому что:

While a swap file may be used on Btrfs when mounted through a loop device, this will result in severely degraded swap performance.

А почему бы и нет.

Так я разве говорю что это что-то плохое? Может я наоборот ищу таких как я.
У меня у самого btrfs на десктопе, ради субвольюмов

Обычный кейс, захотелось потыкать CoW, сжатие и снапшоты.
захотелось потыкать

Т.е. кейс «душа хочет хакерской романтики, а жопа красноглазых приключений»? Ну тогда всё ок, btrfs вполне походит. zfs тоже норм

То есть, нафига мне сжимать 100ГБ данных?

Ага. Ну сэкономишь ты 30 гигов, ну 50… Зачем экономить на спичках? Это ведь HDD, а не SSD

Зачем экономить на спичках? Это ведь HDD

Чтоб то же количество данных прочиталось за меньшее число I/O-операций, например.

Ну засушил ты на 33% корень в 12 гигов. Откуда уверенность что порно с конями очень_важные_документы, занимающие остальные 919 гигов диска, пожмутся так же хорошо?

И в качестве бонуса от CoW получить рандом-аксес вместо линейного чтения

Ага. Ну сэкономишь ты 30 гигов, ну 50… Зачем экономить на спичках?

Гигабайты лишними не бывают, о них вспоминаешь, когда место на диске кончается.

линейного чтения

На хардах его и нет :)

На SSD пофиг.

Расскажи нам, как происходит линейное чтение, например, на массиве raid-6? В контексте каждого отдельного hdd массива.

spijet, King_Carlo
Речь шла о харде, одном. Какой SSD, какой RAID?

Как-раз на хардах-то оно и есть, если не фрагментировать файлы

Ага, вспоминаешь и удаляешь один из BD-ремуксов которые занимают остальные 1900Гб харда

Тут еще надо заметить, что сейчас часто встречаются SSD, в которых контроллер сжимает данные (я вот на Intel 530 напоролся). В этом случае сжатие средствами ФС приводит к падению производительности.

FYI

https://www.intel.com/content/www/us/en/support/articles/000006433/memory-and...

Спасибо, почитаю.

У меня Samsung 840 EVO, который, вроде бы, данные сам сжимать не умеет. Да и вообще слабо представляю, как сжатие на стороне контроллера SSD будет работать так, чтоб ОС об этом знала. :)

Если не фрагментировать файлы и читать их строго линейно и строго по очереди, да. :)

В этом случае сжатие средствами ФС приводит к падению производительности.

к падению дутой производительности

Как бы не столько в этом дело. Сжатие может уменьшить Write Amplification, для этого и сделано. А всё остальное - маркетинговая шелуха. Производительность, кстати, просядет вряд ли.

Производительность, кстати, просядет вряд ли.

Очень сильно проседает, говорю по опыту с тремя SSD на SF-2281 (земля ему стекловатой).

Производительность, кстати, просядет вряд ли.

Если они измеряли (и декларировали) для сжимаемых данных, то просядет.

BD-ремуксов

Аргумент не прокатил. Как я уже сказал, я не держу таких данных. Я говорю про те данные, которые нельзя просто посмотреть и удалить. Вот игры, кстати, весят по 70 или больше гигов и отлично сжимаются. Конечно, их можно удалить, но зачем мне это делать, когда их можно сжать и продолжать использовать. Видео и звуковые файлы сжимаются плохо (точнее никак) даже архиватором, а потом их надо долго-долго распаковывать даже на i7. Остальное вполне себе сжимается.

строго по очереди, да. :)

Или просто один большой файл. Файлы иногда бывают тяжелее мегабайта

Я из таких кейсов (если предположить, что во время чтения файла не будет попыток прочитать/записать что-либо ещё) знаю только просмотр кинца, прослушивание музыки и запись образов на флэшку через dd.

Ну вот сжал ты свою файлопомойку, сэкономил например сотню гигов, сохранил лишних сто гигов очень-важных-файлов. Сотня гигов харда стоит 250 - 500 руб. Столько ты сэкономил. Поздравляю. Уверен что оно того стоило? Учитывая что btrfs это всё ещё минное поле, и задействование каждой дополнительной фичи в лучшем случае не понижает вероятность превращения данных в тыкву. Конкретно компрессия вроде как не повышает вероятность пролюба данных, во всяком случае на оффсайте про это не пишут. Но это не повод терять бдительность

Аргумент про уменьшение объёмов чтения кажется мне гораздо более убедительным. Пожалуй даже пожму корень, а может и хомяк. Один чёрт уже использую btrfs, и бекапится всё раз в три часа. За одно и дефрагментацию сделаю

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

Если я ничего не путаю фрагментироваться может любой файл крупнее блока ФС, а это много что. Допустим есть какой-нибудь pony.png который занимает два блока ФС (по нашим временам это очень компактный пони). Если файл не фрагментирован то его чтение займёт время одного seek-а (временем самого чтения можно пренебречь), если файл фрагментирован то чтение займёт два seek-а. Вдвое больше

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

ОС, конечно, об этом не знает, т.к. сжатие реализовано прозрачно и неотключаемо. С точки зрения кернела это выглядит так, что несжатые данные (т.е. хорошо сжимаемые) пишутся быстрее, чем сжатые (т.е. плохо сжимаемые). Таким образом, полоса пропускания собственно блочного устройства на сжатых данных уменьшается (сильно, иногда в разы). Если компрессия на уровне кернела включена, это падение частично компенсируется за счет сжатия, поэтому доступ к файлам осуществляется лишь на немного меньшей скорости, чем без ядерной компрессии. Почему одно не компенсирует другое полностью — трудно сказать. Может, какая-то интерференция алгоритмов сжатия, может просто оверхед.

На дисках, где этой гадости нет, типа Intel DC Series, все работает так, как ожидается: ядерная компрессия дает заметный положительный эффект. Ниже правильно написали, что они продают лотерейные билеты не ради выигрыша встроили сжатие на ради скорости, а для экономии NAND-чипов.

PS Производительность проседает не по сравнению с заявленными цифрами (что есть маркетинговая шелуха), а по сравнению с несжатым субвольюмом. Слабо, но проседает, хотя должна расти. С intel еще хорошо, они оглашают весь список хотя бы громко и открыто пишут, в каких моделях есть компрессия. На рынке полно безымянных устройств на том же контроллере без всякой документации, и в каких из них тоже компрессия — один черт знает.

Про Samsung — не могу знать, самому интересно.

Сотня гигов харда стоит 250 - 500 руб.

Ты напоминаешь мне адепта сетевого маркетинга, который пытается убедить/переубедить первого попавшегося.

когда ФС или диск превратится в тыкву

Скорее я по запарке отформатирую не тот диск/раздел. Вчера это случилось, благо, тестдиском всё восстановил.

Ты абсолютно уверен

Крон не даст солгать :) Алсо, обычный бэкап перезаписывает предыдущую версию, это не очень удобно, если мне нужны изменения в обеих версиях. Держать два огромных бэкапа одних и тех же данных — не практично, оверхед по месту.