btrfs и компрессия. Как узнать эффективность для отдельного файла?

Во-первых df нельзя верить при btrfs: https://wiki.archlinux.org/index.php/Btrfs#Displaying_used.2Ffree_space

Во-вторых пока это ещё недоступно: https://btrfs.wiki.kernel.org/index.php/FAQ#Can_I_find_out_compression_ratio_... ;

выдержка:

Currently no. There's a patch https://patchwork.kernel.org/patch/117782/ adding the kernel part (ioctl). However, the size obtained by this ioctl is not exact and is rounded up to block size (4KB). The real amount of compressed bytes is not reported and recorded by the filesystem (only the block count) in it's structures. It is saved in the disk blocks but solely processed by the compression code.

Но эта инфа возможно устарела, свежую инфу сейчас только в списках рассылки btrfs узнать можно.

Я так понимаю профит только при чтении сжатых данных? Какая нагрузка на ЦП при записи?

Я так понимаю профит только при чтении сжатых данных? Какая нагрузка на ЦП при записи?

Хотелось и профита от сжатых данных. На том тестовом ноуте крошечный винт.
Я конечно понимаю что линуксу место на серверах и там большие диски - потому так и нет почему то «пакованных фс». Вернее есть - но все больные. В оффтопике ставиш атрибут «сжатое» и оно сжимается - в zfs и btrfs все что записалось несжатым - так и останется несжатым а btrfs скажем при утановке свежего дистра - монтируется непакующим. Потом уже активируешь упаковку а то что уже записано - таким и останется.

Currently no.

Спасибо за знание.

Я разочаровываюсь в btrfs всё больше и больше.

Этот Samsung P28 Ставил Debian Wheezy на btrfs - несолько часов.
Часа через 4 я лег спать... утром встал - оно поставилось.
Скорость работы системы - оставляет желать лучшего.

Но среди пакующих систем для x86 пока альтернативы нет.
zfs можно только на x64 (через zfsonlinux)

Жаль у du нет параметра --one-file-system потому сложно померять размер /

Из всех fs меня пока больше всех прикалывает zfs, но памяти она мег 200 кушает легко - потому на том ноуте пришлось её изжить.

Преимущества в упаковке, статистике, подтомах - каждому из которых можно выбрать свою точку монтирования и точка монтирования запоминается в структуре fs. В итоге грузим скажем zfs из файлового контейнера, делаем подтома и раскидываем по системе (ну скажем /home, /opt). #reboot и поле загрузки честно видимм
/home,/opt смонтированными с zfs

Ну и для #du - zfs честно отдает всю информацию и можно видеть сколько определенный подкаталог со всем его деревом занимает на диске, а с --apparent-size его номинальный размер.

Ну и сегодня при чтении инфы про btrfs неожиданно узнал что это не журналирующая ФС.

Но среди пакующих систем для x86 пока альтернативы нет

reiser4.

Ну и сегодня при чтении инфы про btrfs неожиданно узнал что это не журналирующая ФС

А зачем журналирование при copy-on-write? Это взаимоисключающие техники.

btrfs скажем при утановке свежего дистра - монтируется >непакующим. Потом уже активируешь упаковку а то что уже >записано - таким и останется.

Tip: Compression can also be enabled per-file without using the compress mount option; simply apply chattr +c to the file. When applied to directories, it will cause new files to be automatically compressed as they come.

Это можно совместить с find и проставить атрибут для нужных файлов уже после их записи.

https://wiki.archlinux.org/index.php/Btrfs#Compression

Это можно совместить с find и проставить атрибут для нужных файлов уже после их записи.

Спасибо за очередную порцию знаний, но к сожалению всё не так как обещают.

Сначала решил тупо на упаковнном разделе сделать 10Gb файл - но команда #dd if=/dev/zero of=Zero-10G-1.dat bs=1048576 count=10240
Выполнялась 4 раза каждый раз останавливаясь по исчерпанию места. Лишь после 4 файла ооно действительно исчерпалось и получилось:
# ls -lh
итого 27G
-rw-r--r-- 1 root root 2,9G Окт 19 04:53 Zero-10G-1.dat
-rw-r--r-- 1 root root 7,8G Окт 19 04:54 Zero-10G-2.dat
-rw-r--r-- 1 root root 9,5G Окт 19 04:56 Zero-10G-3.dat
-rw-r--r-- 1 root root 5,6G Окт 19 04:56 Zero-10G-4.dat
-rw-r--r-- 1 root root 512M Окт 19 00:49 Zero-512M.dat

3 Первых раза «место кончалось» с разным размером.
Место закончилось и усё... не могу даже удалить файл - «на устройстве закончилось место» - еще один минус btrfs.

Однако: # lsattr
---------------- ./Zero-512M.dat
---------------- ./Zero-10G-2.dat
---------------- ./Zero-10G-1.dat
---------------- ./Zero-10G-3.dat
---------------- ./Zero-10G-4.dat

Видно что аттрибута +с на них нет.

Впрочем сделал еще один девайс - непакованный, сделал там файл из 0 и места опять почти не убавилось - в итоге залил какой то iso. Снятие/установка +c ничего не дает.

объясните мне - почему люди ставят btrfs?

объясните мне - почему люди ставят btrfs?

я думаю что причины две:

1. там есть subvolume (и их снапшоты). скажи «НЕТ» геморою с lvm :) .

2. там нет жёсткого ограничения по количествую inode (камень в сторону ext4).

3. она быстрая (такая же быстрая как и остальные основные файловые системы. не тормоз короче :)).

все остальные плюшки btrfs — я щитаю это фигня. сжатие тоже считаю что фигня (в файловых системах. любых).

гм...
я если уж и захочу поставить экзотическую ФС, то это вероятнее всего будет reiser4
a о камнях в btrfs я вдоволь начитался и насмотрелся, хз зачем эти сомнительные преимущества кому-то еще нужны

но ведь — в этом-то и фишка — btrfs не является экзотической.

это вполне себе основная файловая система.. мэйнстрим! вполне официальная замена для ext4. также как systemd когда-то заменил старую sysvinit :-) ..

[некоторые люди — ставят btrfs для того чтобы использовать её «суперфишки».. ПРОШУ пожалуйста — НЕ НАДО этого делать :).. используйте btrfs просто как обычную замену для старой ext4]

a о камнях в btrfs я вдоволь начитался и насмотрелся

на старых ядрах небось.. да? :)

объясните мне - почему люди ставят btrfs?

'n0mad'

Хотелось и профита от сжатых данных. На том тестовом ноуте крошечный винт.

Хотел пакованную fs оттестить на тестовом ноуте.
Начиналось всё с zfs но паковать корень можно лишь на x64.

1. там есть subvolume (и их снапшоты). скажи «НЕТ» геморою с lvm :) .

В zfs они тоже есть.

2. там нет жёсткого ограничения по количествую inode (камень в сторону ext4).

У zfs тут тоже всё в порядке.

3. она быстрая (такая же быстрая как и остальные основные файловые системы. не тормоз короче :)).

Тормозилище она. На древнем ноуте ставил Debian Wheezy на btrfs - ставилось 4 часа - потом я пошел спать...

я если уж и захочу поставить экзотическую ФС, то это вероятнее всего будет reiser4

А я вот себе на 3T+2T Винты поставил zfs особо нравится что сейчас в Wheezy она в варианте fuse есть (искаропки).

> 1. там есть subvolume (и их снапшоты). скажи «НЕТ» геморою с lvm :) .

В zfs они тоже есть.

да. верно! но при этом zfs является экзотической файловой системой. а btrfs это основная родная файловая система для GNU/Linux.

> 2. там нет жёсткого ограничения по количествую inode (камень в сторону ext4).

У zfs тут тоже всё в порядке.

да. верно! но при этом zfs является экзотической файловой системой. а btrfs это основная родная файловая система для GNU/Linux.

> 3. она быстрая (такая же быстрая как и остальные основные файловые системы. не тормоз короче :)).

Тормозилище она. На древнем ноуте ставил Debian Wheezy на btrfs - ставилось 4 часа - потом я пошел спать...

нет. она не тормозная.

если у тебя случился какой-то там казус — то сиди и разбирайтя почему он у тебя произошёл.

про старое ядро — я уже говорил выше (не знаю какае там ядро использует установщик Debian Wheezy. сиди и разбирайся).

а что конкретно случилось у тебя (грязный DVD-диск или медленная USB-флешка?) — это можешь узнать только ты. если захочешь разобраться. :-)

я если уж и захочу поставить экзотическую ФС, то это вероятнее всего будет reiser4

Эххх. жаль её искаропки не получается пользовать :(
reiser4progs поставил, контейнер сделал а mount:
# mount 1G.reiser4 1G
mount: unknown filesystem type 'reiser4'

нет. она не тормозная.

Тормозилище. У меня там Линукс с гуем - ползает еле еле.
Он и с другими не быстро шевелился - тут вообще тормоз.

если у тебя случился какой-то там казус — то сиди и разбирайтя >почему он у тебя произошёл.

Нафиг? Нафиг мне эта btrfs нужна?
Тут еще чуть выше добился - «на устройтсве закончилось место»
и нарвался, потому что удалить файл не может потому что «на устройстве закончилось место». Такую ФС фтопку.

Это можно совместить с find и проставить атрибут для нужных файлов уже после их записи.

Я это совместил с: #chattr -VR +c /
и Оно погнало....
Прогнало и сейчас файлы и каталоги имеют атрибут «c» по lsattr
но места не добавилось.

> если у тебя случился какой-то там казус — то сиди и разбирайтя
> почему он у тебя произошёл.

Нафиг? Нафиг мне эта btrfs нужна?

эй, стоп! :) зачем именно тебе нужна btrfs?

именно тебе быть может она и не нужна.. (это просто обычная файловая система.. а ты может хочешь что-то экстраординарное и необычное?)

а вот: зачем тебе разбираться с твоей проблемой с ноутбуком, в момент когда ты использовал btrfs?"

ответ: чтобы на форумах ты не заниматься неконструктивным балобольством :-)

Прогнало и сейчас файлы и каталоги имеют атрибут «c» по lsattr

но места не добавилось.

команда btrfs filesystem defragment ... имеет ключи -c и -r (т.. е.. — совмещать с find её не надо).

я проверял — свободное место увеличивается

эй, стоп! :) зачем именно тебе нужна btrfs?

Хотел упаковку и быструю работу.
Не полчил ни того ни другого.
Мало того - выяснил что когда заканчивается место - не могу удалить файл для освобождения места. fsck не помог.
Изменение аттрибута «упакованный» тоже не приодит к «упаковке/распоковке».
Получить статистику сжатия тоже невозможно.
Итого 1,2,3 минуса - следовательно как продакшн она меня не устраивает.

команда btrfs filesystem defragment ... имеет ключи -c и -r (т.. е.. — совмещать с find её не надо).

-----
# btrfs filesystem defragment -c -r /
btrfs filesystem defragment: invalid option — 'r'
usage: btrfs filesystem defragment [options] <file>|<dir> [<file>|<dir>...]

Defragment a file or a directory

-v be verbose
-c[zlib,lzo] compress the file while defragmenting
-f flush data to disk immediately after defragmenting
-s start defragment only from byte onward
-l len defragment only up to len bytes
-t size minimal size of file to be considered for defragmenting
-----

я проверял — свободное место увеличивается

Запуск без -r - время выполнения пара секунд и место не увеличивается.
Только сейчас проверил. Как было 3.9G свободных так и осталось.

Итого 1,2,3 минуса - следовательно как продакшн она меня не устраивает.

ты уж определись — либо для продакшена либо для тебя. :-)

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

про то что у тебя файл не удалился — про это я вообше пытался тактично промолчать.. но в итоге похоже так и не получилось, и я вот написал это строчку: СМЕШНО ЭТО! более девяти тысяч раз у меня файлы удалялись :), делал я разные эксперименты, в том числе и заканчивал всё свободное место.

со сжатием я пробовал экспериментировать — и при этом свободное место у меня увеличивалось (разумеется не сразу после операции, а с задержкой).

Хотел упаковку и быструю работу.
Не полчил ни того ни другого.

ну повторю ещё раз. если ты хочешь чего-то экстраординарного — то это именно твои индивидуальные интересы.

например захотел ты заиспользовать говномамонтовское железо — ПРАВО ИМЕЕШЬ на это — но при этом уж будь добр НЕ хай мой уютный линукс КЛЕВЕТОЙ (а btrfs это необъемлемая часть линукса, в отличии от zfs) :-)

btrfs filesystem defragment: invalid option — 'r'

ой, интересно.. и почему же это так произошло..

[/сарказм]

:-D

некоторые люди — ставят btrfs для того чтобы использовать её «суперфишки».. ПРОШУ пожалуйста — НЕ НАДО этого делать

ещё какую глупость скажешь?

btrfs как раз и стоит использовать из-за её «суперфишек»

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

к тому же, zfs не в ядре (+500 к траху при сборке ядра), имеет свой собственный кэш, который настраивается через раз, ну и логика работы с клонами и снапшотами там кретинская

btrfs, естественно, тормозит на хардах при включенном cow

Нафиг мне эта btrfs нужна?

не нужна - и иди гуляй, чего раскукарекался тут?

дело в том что линуксовское окружение не очень хорошо доработано для этих «суперфишек»..

например не думаю что initramfs всегда будет ждать пока udevd найдёт все-все-все физические диски для мультидискового устройства.. (а вот ситуация с mdadm внутри initramfs — обычно хорошо продумана. в отличии ситуации с мультидисковым устройством btrfs)

и да, говорю заранее что btrfs device scan тут не поможет, так как проблема не в файловой системе, а в окружении.

ну и другие могут вплыть неприятности при использовании «суперфишек», мало ли :-)

но при этом уж будь добр НЕ хай мой уютный линукс КЛЕВЕТОЙ (а btrfs это необъемлемая часть линукса, в отличии от zfs) :-)

Linux это идеология Unix и SUN Solaris тоже.
Причем zfs проверенная временем система которую делали профессионалы.

Впрочем часть ответов на вопросы я получил.
Узнать статистику упаковки - невозможно.
Атрибуты упаковки должны в онлайне паковать но почему то не пакуют.
Дефрагментация с компрессией тоже не работает.
btrfs у меня та что в дистрибутиве Debian Wheezy.

btrfs у меня та что в дистрибутиве Debian Wheezy

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

не думаешь или знаешь? в чём проблема узнать?

кстати, ты не в курсе, что за новая строка появилась в выводе btrfs filesystem df в версии 3.16.х?

# btrfs filesystem df /
Data, single: total=67.47GiB, used=16.39GiB
System, single: total=4.00MiB, used=16.00KiB
Metadata, single: total=6.01GiB, used=1.29GiB
GlobalReserve, single: total=396.00MiB, used=0.00

да, точняк :) .. я и не заметил сразу

не думаешь или знаешь? в чём проблема узнать?

дело в том что на практике описанная проблема у меня НЕ возникала. однако судя по исходным кода арчиковского initramfs (и с учётом его хукув) — это проблема возникнуть может. как я предполагаю (да, именно предполагаю).

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

бывает такое на практике? если не бывает, то значит действительно и проблемы нет :-) ..

вот dracut я не смотрел.. а надо посмотреть..