LINUX.ORG.RU

Сжатие btrfs

 ,


0

3

Всем привет. Решил попробовать ЛUbuntu на ФС btrfs. Пациент - старый нетбук с SSD на 4 Гб Поставил систему из-под LiveCD, раздел при установке отформатировал в btrfs. После окончания установки перед перезагрузкой внес изменения в fstab установленной системы, чтобы включить сжатие (/boot на отдельном разделе ext2). Все отлично работает, новые данные сжимаются и довольно неплохо. А теперь вопрос: хочу сжать все данные на этом HDD, а не только вновь записываемые. Для этого придумал следующую схему: при помощи rsync или cp слить все с корня на другой диск, удалить, а затем влить обратно(при этом, разумеется, корневой раздел с btrfs будет примонтирован с включенным сжатием). Если я правильно понял принципы работы сжатия btrfs, при этом все, что может быть сжато, должно сжаться на лету при копировании обратно. Получится ли осуществить задуманное?

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

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

King_Carlo ★★★★★ ()
btrfs filesystem defrag -r -c /

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

crowbar ()

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

btrfs filesystem defragment -r -v -czlib /mnt/btrfs
Можно и с того же загрузиться, там всего лишь то открытые файлы не сожмутся. Также можно и без ext2 /boot раздела обойтись, да и вообще без разделов. Это отличная файловая система для SSD и прочих флешек. Я тестирую её начиная с ядер 3.4.x, она становится всё лучше и лучше.

armbox ()
Ответ на: комментарий от armbox

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

armbox ()
Ответ на: комментарий от armbox

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

AlexPRN ()

Всем спасибо. Воспользовался 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
lzo:
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
zlib:
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

AlexPRN ()
Ответ на: комментарий от armbox

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

King_Carlo ★★★★★ ()
Ответ на: комментарий от King_Carlo

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

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

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

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

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

anonymous ()
Ответ на: комментарий от King_Carlo

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

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

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

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

user_id_68054 ★★★★★ ()
Ответ на: комментарий от user_id_68054

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

anonymous ()

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

anonymous ()
Ответ на: комментарий от user_id_68054

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

King_Carlo ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

vurdalak ★★★★★ ()
Ответ на: комментарий от King_Carlo

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

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

anonymous ()
Ответ на: комментарий от King_Carlo

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

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

sdio ★★★★★ ()
Ответ на: комментарий от vurdalak

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

anonymous ()
Ответ на: комментарий от sdio

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

devl547 ★★★★★ ()
Ответ на: комментарий от sdio

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

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

King_Carlo ★★★★★ ()
Ответ на: комментарий от King_Carlo

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

sdio ★★★★★ ()
Ответ на: комментарий от King_Carlo

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

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

sdio ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

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

EvgGad_303 ★★★★★ ()
Ответ на: комментарий от King_Carlo

он не будет сжат 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

redgremlin ★★★★★ ()
Последнее исправление: redgremlin (всего исправлений: 1)
Ответ на: комментарий от redgremlin

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

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

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

да

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

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

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

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

King_Carlo ★★★★★ ()
Последнее исправление: King_Carlo (всего исправлений: 2)
Ответ на: комментарий от EvgGad_303

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

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

King_Carlo ★★★★★ ()
Ответ на: комментарий от King_Carlo

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

EvgGad_303 ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

King_Carlo ★★★★★ ()
Ответ на: комментарий от King_Carlo

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

vurdalak ★★★★★ ()
Ответ на: комментарий от vurdalak

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

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

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

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

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

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

King_Carlo ★★★★★ ()
Последнее исправление: King_Carlo (всего исправлений: 1)
Ответ на: комментарий от King_Carlo

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

Прекрати. Пороть. Чушь. Файл образа будет сжиматься всегда. По одной простой причине — из самой структуры следует, что данные в первом блоке будут сжимаемыми — это либо информация о структуре образа (например, в случае 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) — везде сжимает.

redgremlin ★★★★★ ()
Ответ на: комментарий от EvgGad_303

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

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

redgremlin ★★★★★ ()
Ответ на: комментарий от redgremlin

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

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

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

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

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

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

King_Carlo ★★★★★ ()
Ответ на: комментарий от EvgGad_303

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

anonymous ()
Ответ на: комментарий от King_Carlo

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

anonymous ()
Ответ на: комментарий от redgremlin

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

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

King_Carlo ★★★★★ ()
Ответ на: комментарий от redgremlin

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

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

EvgGad_303 ★★★★★ ()
Ответ на: комментарий от King_Carlo

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

+1

axelroot ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.