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

оно не для hdd

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

А как же опция nossd?

Ну как же так

очень просто - copy-on-write на накопителях с низкой скоростью случайного доступа приводит к тормозам, а на ssd - всё ок

нет такой опции

Нет есть

докажи

nossd
(default: SSD autodetected)
Options to control SSD allocation schemes. By default, BTRFS will enable or disable SSD allocation heuristics depending on whether a rotational or non-rotational device is in use (contents of /sys/block/DEV/queue/rotational). If it is, the ssd option is turned on. The option nossd will disable the autodetection.

https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs(5)

Пожалуйста:
https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs(5)

хорошо

но сказанного выше это не отменяет

2 - ну примерно как хардлинки

3 - сколько сделаешь, верхняя оценка - объём занятого пространства в момент создания

4 - сколько сделаешь, столько и будет, ну а ненужные удалишь

3 - сколько сделаешь, верхняя оценка - объём занятого пространства в момент создания

Это похоже на то, как работает инкрементальный бэкап, то есть, это как сперва создается полный бэкап, а дальше добавляются только измененные данные.

Как работают CoW и снапшоты?

Ну, CoW - оно и в африке CoW. Плюс к этому снапшоты в Btrfs используют технику «ленивых счётчиков» ссылок на дереве. Есть статья 2008 года за авторством некоего Охада Родеха.

Как не допустить проблем вида «No left Space on device» (недавно был такой тред, там ТС решил эту проблему подстановкой другого накопителя со свободным пространством)

На Btrfs никак. Broken by design.

Каким образом достигается минимальная накладка по дисковому пространству?

В Btrfs она не достигается. Разработчики не заморачивались экономией дискового пространства.

Требует ли сабж особого обслуживания?

«Будь готов - всегда готов!» бежать в магазин за новым диском.

Ты забыл рассказать, зачем оно тебе.

Как работают CoW и снапшоты?

ЕЯВПП — при записи блок копируется и после успешной записи в ФС меняется ссылка на этот блок. Снапшоты используют CoW, но не «освобождают» старые блоки (ссылки на них остаются внутри снапшота).

Каким образом достигается минимальная накладка по дисковому пространству?

Что ты имеешь ввиду? Накладные расходы на метаданные? Ну, у меня на сжатые 15 гигабайт данных с кучкой снапшотов занято около гигабайта:

Data,single: Size:21.00GiB, Used:15.79GiB
   /dev/mapper/root	  21.00GiB

Metadata,single: Size:1.75GiB, Used:1.00GiB
   /dev/mapper/root	   1.75GiB

Можно ли регулировать количество снапшотов?

Можно, конечно. Либо не создавать лишние, либо ротировать старые (например, snapper и создавать и ротировать умеет).

Как не допустить проблем вида «No left Space on device» (недавно был такой тред, там ТС решил эту проблему подстановкой другого накопителя со свободным пространством).
Требует ли сабж особого обслуживания?

В том же треде мы на пару с intelfx всё рассказали. Балансируй ФС хотя бы раз в месяц и твои волосы будут чистыми и шёлковистыми. Или поставь btrfsmaintenance и вообще забудь о том, что у тебя там могут какие-то незаполненные блоки копиться.

P.S. Есть отдельный хард, который можно использовать с сабжем.

CoW-ФС плохо дружат с HDD. Не жди, что оно будет быстро работать при использовании снапшотов. Если будешь снапшотить без фанатизма и не забудешь про сжатие и опцию autodefrag — будет работать вполне сносно.

Как работают CoW и снапшоты?

Примерно так же, как и везде. Тебе технически или логически?

Каким образом достигается минимальная накладка по дисковому пространству?

Хах, «минимальная» — как уже сказали, это не про btrfs.

Сколько весят снапшоты? 10% от общего объема диска? 20%?

Снапшоты весят ровно столько, сколько ты на них запишешь. То есть расход места на снапшот равен суммарному объёму записи на снапшот и на исходник по отношению к точке снятия снапшота.

Оверхед на метаданные — ну, наверное, логарифм от количества изменённых экстентов. Не замечал особых проблем с разрастанием метаданных.

Можно ли регулировать количество снапшотов?

Снапшоты ты создаёшь вручную, если ты об этом.

Как не допустить проблем вида «No left Space on device» (недавно был такой тред, там ТС решил эту проблему подстановкой другого накопителя со свободным пространством).

Периодически запускать btrfs balance. Выше по треду говорят про какие-то скрипты, которые могут это автоматизировать, но я не пользовался.

Требует ли сабж особого обслуживания?

См. выше.

хард

Готовься к страданиям.

Примерно так же, как и везде. Тебе технически или логически?

Выше уже написали.

Готовься к страданиям.

Гугл намекает, что тормоза вроде бы починили после 2015 года и сейчас всё ОК.

Накладные расходы на метаданные?

Да.

Ну, у меня на сжатые 15 гигабайт данных с кучкой снапшотов занято около гигабайта:

Тогда всё ОК.

CoW-ФС плохо дружат с HDD. Не жди, что оно будет быстро работать при использовании снапшотов.

Это понятно, главное, чтобы сильных тормозов не было, хотя если хард не системный, то это не так уж и важно.

Благодарю за ответы. Теперь будем ждать случая и повода использовать сабж. С другой стороны можно обойтись Ext4 + инкрементальные бэкапы.

Периодически запускать btrfs balance.

А balance нужно для каждого subvolume отдельно делать?

Нет, это глобальная (для раздела) операция.

Как вышло, что ты решил, что оно нужно сразу после того, как эту дрянь дропнул Редхат?

Не сразу. Просто подумалось, что неплохо бы хранить данные на ФС, которая лучше всего подходит для хранения файлов. У ext4, например, нет сжатия файлов и снапшотов.

ну дык переходи сразу к zfs там вообще усё неограничено :)

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

Видел хвалебную статью о ZFS on Linux где-то. С неё по-моему только грузиться нельзя, а так и CoW, и снапшоты, сжатие, всё робит. Это, конечно, не оригинальная ZFS, но я бы на твоём месте смотрел в её сторону, а не в сторону изотерического поделия.

А ты пробовал под линуксом?

Грузиться можно. Но: 1. воюет с ядром за память; 2. не одобрена корпроациями для продакшна.

ZFS прекрасна, но меня удручает то, как работает ARC с VFS-кэшем (или VFS-кэш с ARC, я ещё не определился). Btrfs — вполне себе достойный аналог ZFS для линукса. Не такой фичастый (нет аналогов ZVOL и, соответственно, возможности их экспорта, и ещё каких-то там фич), но что есть — работает не хуже (по крайней мере не хуже, чем ZoL).

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

Явно не то.

нет аналогов ZVOL и, соответственно, возможности их экспорта

Что такое «экспорт zvol»? Файл в loopback — чем не аналог?

Не такой фичастый

У btrfs по сравнению с zfs зато есть одна киллер-фича: рестрайп и ресайз вниз.

у zfs тоже есть одна киллер-фича: дисковое пространство не приказывает бежать в магазин за новым драйвом.

Про рестрайп/баланс и ресайз вниз согласен (хотя второй мне ни разу не потребовался при использовании ZFS).

Что такое «экспорт zvol»? Файл в loopback — чем не аналог?

ЕМНИП, файл с loopback на btrfs медленнее, чем ZVOL у ZFS. Под экспортом я имел ввиду встроенную (в Illumos и FreeBSD) возможность экспортить тома или ZVOL как NFS/SMB или iSCSI соответственно.

ЕМНИП, файл с loopback на btrfs медленнее, чем ZVOL у ZFS

А с чем это связано?

Под экспортом я имел ввиду встроенную (в Illumos и FreeBSD) возможность экспортить тома или ZVOL как NFS/SMB или iSCSI соответственно.

Но ведь то же самое можно сделать и в линуксе?

Под экспортом я имел ввиду встроенную (в Illumos и FreeBSD) возможность экспортить тома или ZVOL как NFS/SMB или iSCSI соответственно.

У них там прямо в ZFS встроены свои SMB/NFS и iSCSI target?

А ты попробуй сделать в ZFS RAID-массив, заполнить его процентов на 80 смешанной нагрузкой и посмотреть на linear throughput. Побежишь не просто за новым драйвом, а за пачкой новых драйвов такого же или кратного размера, потому что производительность деградирует, а ни рестрайпа, ни ресайза, ни дефрагментации :)

А ты попробуй от темы виртуотзно не увиливать и посчитать удельное число жалоб на no space left on device в листах рассылок btrfs и zol.

.. Балансируй ФС ..
.. поставь btrfsmaintenance...

а потом ещё что-то надо будет поставить для полного счастья... вот же клуб костылефилов-извращенцев :(

…помогающие улучшить надежность хранения…

Ты перепутал btrfs и backup

Про CoW и его снапшоты по идее должно быть вменяемо написано в какойнибудь википедии или ещё чём-то с первой страницы выдачи гугла

Просто подумалось, что неплохо бы хранить данные на ФС, которая лучше всего подходит для хранения файлов

Тогда у тебя опечатка в слове ext4.
Тебе точно нужно сжатие? У тебя много хорошо сжимаемых данных? Может есть смысл сжать их каким-нибудь bzipом (или что там сейчас модно-молодёжно) и хранить в сжатом виде?
ИМХО для хранения лучше использовать что-то максимально надёжное, т.е. максимально тупое, т.е. ext4

Как работают CoW и снапшоты?

Грубо говоря, данные помечаются записанными, но по факту пищутся только когда надо. Например, создать можно файл размером 1 Тбайт, но фактически заполненный нулями и размером в пару килобайт. Это есть CoW. Снапшоты - это в метаданных помечается что вот с такого момента накапливаем изменения, не трогая саму ФС. То есть снапшот весит столько, сколько изменилось с его создания. Сделал снапшот, записал 10 гиг - он ниче не весит. Снёс 10 гиг которые были до создания снапшота - вот вес снапшота и есть.

Можно ли регулировать количество снапшотов?

Не знаю, есть ли из коробки, но в общем да. Ты ж их делаешь по каким-то поводам... Скриптом в кроне удалять старше какой-то даты...

Как не допустить проблем вида

Никак, это By Design. Но в целом фс поставляется с утилями, которые запускаяст что-то делают для сведения вероятности появления таких проблем к нулю.

Требует ли сабж особого обслуживания?

Скорее, особой настройки.

Для одного харда там особо преимуществ не много. Это такое подобие ZFS. Этим комбайном можно заменить mdadm, lvm в том числе, за что его и не любят (нафакапить легче).

Это похоже на то, как работает инкрементальный бэкап

Это ниразу не бэкап. Разве что своеобразная «корзина». От порчи ФС или железа не защищает никак, а ФС с приколами.

Может есть смысл сжать их каким-нибудь bzipом (или что там сейчас модно-молодёжно)

Да, но в таком случае не было бы необходимости изобретать компрессию на уровне ФС (Даже у NTFS есть сжатие файлов и теневые копии). Обычный тарбол надо разжимать, чтобы работать с его содержимым, в то время как сжатый файл — не тарбол и работа с ним происходит напрямую.

Снапшоты при моем юзкейсе содержат несколько версий одного файла, с обычным бэкапом это будет неудобно.

ИМХО для хранения лучше использовать что-то максимально надёжное, т.е. максимально тупое, т.е. ext4

Согласен. Ext4 уже используется для / и /home, для остальных данных можно попробовать использовать сабж.

Так тебе файлы хранить или работать с ними? Я так понял что речь шла о, в основном, архивном хранении

Грубо говоря, данные помечаются записанными, но по факту пищутся только когда надо. Например, создать можно файл размером 1 Тбайт, но фактически заполненный нулями и размером в пару килобайт. Это есть CoW.

Ты что-то путаешь. Это разреженные файлы. CoW (copy on write) это когда при записи например изменений в файл новая версия данных записывается не поверх старой, а в свободный блок на диске

Мне важно, чтобы они занимали чуть меньше места и не были архивами.

. CoW (copy on write) это когда при записи например изменений в файл новая версия данных записывается не поверх старой, а в свободный блок на диске

Это именно то, что нужно.

Это именно то, что нужно.

Нужно зачем?

P.S.
Купи диск на четыре тера, если мало то купи два. Использую какую-нибудь FUSE-прослойку сжимающую данные. Вообще я слабо представляю что такой нужно хранить чтобы оно хорошо сжималось и при этом весило действительно много. Зеркало гитхаба?

Это не бэкап, но годный инструмент для бэкапов. Управлять бэкапами с помощью btrfs было бы удобно. Жаль только, что сейчас это работает только в SLE15. В RHEL/Centos сломан ядерный драйвер. Нет, данные не повреждает, но когда дело доходит до кросс-подтомов (или как это правильно называется) — начинаются проблемы. Этот баг исправили в F20, но исправления никто не бэкпортировал. Есть еще рискованный вариант UEK.

Остается только довольно удобный костыль по имени rear.

Да, ЕМНИП.

максимально надёжное, т.е. максимально тупое, т.е. …

FAT. :)

Ну например, так у меня выглядит разбивка по алгоритмам сжатия на корневой ФС (всё, кроме хомяка):

Processed 483946 files, 222920 regular extents (228081 refs), 303488 inline.
Type       Perc     Disk Usage   Uncompressed Referenced  
TOTAL       50%      6.5G          12G          13G       
none       100%      3.4G         3.4G         3.5G       
lzo         57%      8.6M          14M          14M       
zstd        32%      3.1G         9.5G         9.9G       

Тут Perc — показатель сжатия.