Сжатие btrfs

Получится ли осуществить задуманное?

Лишь отчасти. Если начало файла не сжимается, то весь файл не будет сжат. Я это дело тестировал на файлах-образах виртуальных машин. Берём файл ВМ 100Гб почти пустой, но с ОС вначале (2-3 Гб), он не будет сжат btrfs даже с опцией монтирования compress-force, потому что MBR не сжимается. Кроме того, деградация скорости в процессе работы btrfs беспрецедентна. Это убогая файловая система. Я тестирую её начиная с ядер 3.12.x, лучше она не становится.

btrfs filesystem defrag -r -c /

Но лучше прислушайся к совету товарища выше.

Загрузись с другого диска, смонтируй раздел с btrfs, затем :

btrfs filesystem defragment -r -v -czlib /mnt/btrfs

пишу с системы на btrfs флешке со сжатием, ext4 дико тормозила, btrfs летает

Берём файл ВМ 100Гб

заглавный пост то прочти ;)

Прочитал, что GRUB2 не умеет грузиться с раздела btrfs, пожатого lzo. Поэтому сделал /boot отдельный. А lzo выбрал из-за того, что он работает быстрее zlib судя по тестам.

Всем спасибо. Воспользовался btrfs filesystem defrag.

Если кому интересно, выкладываю сравнение эффективности алгоритмов сжатия. Сначала сделал defrag с ключом -clzo, потом запустил еще раз с ключом -zlib.

До сжатия:

alex@alex-900:~$ btrfs filesystem df /
Data, single: total=2.10GiB, used=1.61GiB
System, DUP: total=8.00MiB, used=16.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, DUP: total=690.00MiB, used=127.25MiB
Metadata, single: total=8.00MiB, used=0.00

alex@alex-900:~$ btrfs filesystem df /
Data, single: total=2.10GiB, used=1.39GiB
System, DUP: total=8.00MiB, used=16.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, DUP: total=690.00MiB, used=126.72MiB
Metadata, single: total=8.00MiB, used=0.00

alex@alex-900:~$ btrfs filesystem df /
Data, single: total=2.10GiB, used=1.18GiB
System, DUP: total=8.00MiB, used=16.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, DUP: total=690.00MiB, used=126.48MiB
Metadata, single: total=8.00MiB, used=0.00

Я лишь пример привёл, то же самое справедливо и для мелких файлов.

прежде чем снова кукарекать, осиль прочитать то, что пишет ТС:

Если я правильно понял принципы работы сжатия btrfs, при этом все, что может быть сжато, должно сжаться на лету при копировании обратно. Получится ли осуществить задуманное?

специально для тебя: он и не рассчитывал, что будет сжато всё

Кроме того, деградация скорости в процессе работы btrfs беспрецедентна. Это убогая файловая система. Я тестирую её начиная с ядер 3.12.x, лучше она не становится.

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

Кроме того, деградация скорости в процессе работы btrfs беспрецедентна.

«деградация» — что это значит. расшифруй.

имееШЬ ЛИ ты ввиду что сначала скорость работы файловой системы нормальная, а потом через месяц (или год) становится медленной?

если ответ «да» — то говорю сразу что такого эффекта не наблюдается.

знаешь детскую игру «дуб, орех или мочало»? вот у Карлиты - вечное «мочало - начинаем всё сначала», ему хоть что доказывай, он будет своё долдонить, как попугайчик, ведь его сисодминские опыты вперемешку с откровенным враньём - это истина в последней инстанции, бгг

вообще, Btrfs не очень подходит для HDD из-за CoW, а если монтировать с опцией nodatacow, то сжатие не будет работать

Ответ да. Сделал тестовые стенд с 2x3Тб wd RE в raid1 средствами btrfs, сжатие включено Залил туда файлы с виртуальными машинами, каждую в свой subvolume, общий размер около 1Тб. ВМ работают, скрипт делает снапшоты ежечасно, старые снапшоты не удаляю. Через месяц скорость чтения упала до 40Мб/сек, хотя на свежей ФС была около 150Мб/сек.

не очень подходит для HDD из-за CoW

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

скрипт делает снапшоты ежечасно, старые снапшоты не удаляю

да, всего лишь забыл уточнить, лол

скорость чтения упала до 40Мб/сек, хотя на свежей ФС была около 150Мб/сек.

COW --> фрагментация. На zfs таже картина, я приводил пруф.

што? разупорись, несёшь не знамо что

На zfs таже картина

ща у фонната рванёт, запасаемся попкорном

Btrfs не очень подходит для HDD из-за CoW

ЕМНИП, мне тут уже рекомендовали какую-то опцию, которая исправляет тормоза на HDD. Или я это с reiser4 путаю.

COW --> фрагментация. На zfs таже картина, я приводил пруф.

Но не до такой же степени. На zfs, при необходимости,можно подтянуть скорость выделив больше ОЗУ или добавить L2ARC на ssd. В доках на zfs сказано, что есть встроенные эффективные алгоритмы снижения фрагментации и, очевидно, они работают.

Вопрос в цене, то кричат RAM дешевая, то убивают друг друга с криком «ваш скрипт на БАШе жрет 5Мбайт, а тоже самое на С 3,5Мб РАМ»

В доках на zfs сказано, что есть встроенные эффективные алгоритмы снижения фрагментации и, очевидно, они работают.

Абсолютно не очевидно, их неэффективность маскируется жирным РАМ-кешем.

скрипт делает снапшоты ежечасно, старые снапшоты не удаляю

да, всего лишь забыл уточнить, лол

а что в этом такого? я понимаю lvm - там это by design, выходит, ботеэр такая же дефективная.

он не будет сжат btrfs

Чушь. Как раз из-за особенностей формата образов они сжиматься будут всегда. Выбор сжимать или не сжимать система делает по результатам сжатия первого блока, который у виртуальных образов сжимается хорошо.

dd if=Debian6.vdi of=test.bin bs=128k count=1
1+0 записей считано
1+0 записей написано
 скопировано 131072 байта (131 kB), 0,0168074 c, 7,8 MB/c
gzip test.bin
ls -l test.bin.gz 
 -rw-r--r-- 1 redgremlin redgremlin 46803 Янв 14 13:32 test.bin.gz

даже с опцией монтирования compress-force

Бред чистой воды. При compress-force сжимается всегда, даже если занятое место при этом будет увеличиваться.

потому что MBR не сжимается

При чём здесь MBR? Размер блока сильно больше MBR.

Кроме того, деградация скорости в процессе работы btrfs беспрецедентна

RTFM не читаем, снепшоты используем? https://btrfs.wiki.kernel.org/index.php/Mount_options#Performance

дефективность в самой концепции CoW, дурилко

ну-ну, zfs по барабану сколько снэпов сделано. ты ведь в курсе, что реализации cow разные бывают, умник?

zfs по барабану сколько снэпов сделано

пруф или балабол

Чушь. Как раз из-за особенностей формата образов они сжиматься будут всегда.

Если в файле-образе ВМ установлена ОС, то он не сжимается, так как первый блок несжимаем. Проверено неоднократно.

по результатам сжатия первого блока

да

который у виртуальных образов сжимается хорошо.

нет. Выше написал об этом.

Бред чистой воды. При compress-force сжимается всегда

На ядре 3.17.6 не сжимает (force игнорируется), на ядре 3.17.8 сжимает, на ядре 3.17.1 kernel panic при включении compress-force. Это btrfs, она непредсказуема.

ну-ну, zfs по барабану сколько снэпов сделано.

Абсолютно верно с одним уточнением - если есть свободное место в пуле, хотя бы 20% от общего размера. При том же паттерне работы, который я описал выше, zfs не теряет скорость хоть сколько нибудь заметно.

если есть свободное место в пуле, хотя бы 20% от общего размера

и если есть десяток-другой гигов рамы

не, всё-таки фанбои zfs доставляют: человек пришёл с конкретным вопросом по btrfs, даже не с вопросом - уточнением, но фанбои zfs влезли в тему и устроили пляски с воплями про сжатие образов виртуальных машин и деградацию скорости при тысячах снапшотов

диагноз - таки да, лол

т.е. что бывают разные реализации ты не в курсе и обосновать почему должны тормозить снэпы из-за cow ты не можешь?
тогда пока что балабол - это ты.

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

А ничего, что это тот самый функционал, который отличает btrfs от классических ФС? Я лишь пытаюсь донести мысль о том, что эти фичи сделаны плохо и в реальных условиях слабо применимы.

Тут недавно был тред, где один пытался удалить из каталога 100 000 файлов. И у него не получалось. Из этого следует, что линукс в реальных условиях неприменим? Пофиг что снапшоты работают, реальные условия — это ведь исключительно миллиарды снапшотов на доисторическом железе.

один пытался удалить из каталога 100 000 файлов. И у него не получалось.

Не читал тот тред, но не понимаю в чём может быть проблема, 100000 файлов в каталоге это немного.

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

Из этого вообще ничего не следует.

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

Нормальное железо, серверные hdd, снапшотов всего то около 8000, куча свободного места на диске.

Если в файле-образе ВМ установлена ОС, то он не сжимается

Прекрати. Пороть. Чушь. Файл образа будет сжиматься всегда. По одной простой причине — из самой структуры следует, что данные в первом блоке будут сжимаемыми — это либо информация о структуре образа (например, в случае VDI), либо данные самого диска (например, в случае VDMK), где в начале идут служебные сжимаемые части (информация о разделах, GRUB2 stage 1.5, служебные данные ФС).

Проверено неоднократно.

А вот врать нехорошо.

На ядре 3.17.6 не сжимает (force игнорируется), на ядре 3.17.8 сжимает, на ядре 3.17.1 kernel panic при включении compress-force

Ссылки на багзиллу. Проверил на ядрах 3.14.25 (ROSA 2014.1), 3.16.7 (Debian Jessie), 3.17.7 (Gentoo x86) — везде сжимает.

обосновать почему должны тормозить снэпы из-за cow ты не можешь?

А нафига это обосновывать? Тормоза возникают из самой природы COW и это известно каждому, кто понимает, как работает COW, а кто не понимает — ну так нафига идиотам что-то обосновывать?

Прекрати. Пороть. Чушь. Файл образа будет сжиматься всегда.

Нет. RAW с установленной ОС и опцией compress не сжимается, с compress-force сожмётся, если раньше не случится kernel panic.

А вот врать нехорошо.

Я до такого не опускаюсь.

Ссылки на багзиллу.

Я не писал в багзилу.

Нет. RAW с установленной ОС и опцией compress не сжимается

dd if=image.raw of=proof.dat bs=128k count=1 в студию!

лолка, пруфы где? нету? свободен

о да, реальные условия - это же исключительно твои одминские юзкейсы с тысячами снапов виртуальных машин, а всё остальное - это нереальные игрушки, ага

dd if=image.raw of=proof.dat bs=128k count=1 в студию!

Ты уверен, что хочешь увидеть выхлоп именно этой команды?

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

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

Даже не представляю.

ну так нафига идиотам что-то обосновывать?

это ты правильно про себя подметил - ведь идиоты не могут обосновывать.
ни разу не слышал от клиентов о проблемах производительности даже при 10к снэпов на zfs. а то, что lvm плохеет от снэпшотов, так это и не новость.

zfs по барабану сколько снэпов сделано
с одним уточнением - если есть свободное место в пуле, хотя бы 20% от общего размера. При том же паттерне работы, который я описал выше, zfs не теряет скорость хоть сколько нибудь заметно.

+1

ZFS вообще не включена в mainline ядро, видимо есть на то основания

Конечно есть - жо-пе-эль называется.

Конечно есть

смысл про неё упоминать, если речь идёт о linux ?

смысл про неё упоминать, если речь идёт о linux ?

Ядерный модуль http://zfsonlinux.org/

Ядерный модуль http://zfsonlinux.org/

знаю, ток мне оно ненужно, в серверах на работе - ntfs и ext4 поверх аппаратных raid и дисковых полок, а в домашних компах - btrfs на флешке