LINUX.ORG.RU

Прозрачное сжатие Btrfs при помощи Zstd по умолчанию в Fedora 34

 , ,


0

4

В десктопных спинах Fedora, уже сейчас использующих по умолчанию файловую систему Btrfs, планируют по умолчанию включить прозрачное сжатие данных при помощи библиотеки Zstd от Facebook. Речь идёт о будущем релизе Fedora 34, который должен появиться в конце апреля. Помимо экономии дискового пространства прозрачное сжатие данных так же призвано уменьшить износ SSD и прочих флеш-накопителей. Кроме того, ожидается прирост в производительности при чтении и записи.

Использование прозрачного сжатия будет иметь влияние и на работу некоторых утилит, таких как du, поскольку размер файла может существенно отличаться от занимаемого им дискового пространства. В качестве альтернативы предлагаются к использованию утилиты вроде compsize.

>>> Подробности



Проверено: Shaman007 ()

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

Есть вообще какие-то уважительные причины, по которым это нормально не работает столько лет, когда в ZFS как-то ухитрились сделать, чтобы не были нужны костыли?

nas % du /mnt/file 
1,0K	/mnt/file
nas % du --apparent-size /mnt/file 
1,0G	/mnt/file
anonymous ()
Ответ на: комментарий от AVL2

Несомненно, но в большинстве случаев — нормально работающий :) Я обычно использую Btrfs, но хотелось пристроить куда-то три старых куска ржавчины, а она не может в RAID5. Так что пробую ZFS ровно в той среде, для которой она задумана, и в чём-то она получше.

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

С какого перепугу?

Вот я тоже пока не понял, но у них так в wiki написано. Может быть имеется в виду то, что zstd работает быстрее разницы по времени на запись или чтение несжатых данных?

hummer ()

планируют, так же по умолчанию, включить прозрачное сжатие данных при помощи библиотеки Zstd от Facebook

кто б сомневался. такое чувство, что не RH определяет курс, а FB.

crypt ★★★★★ ()

В качестве альтернативы предлагаются к использованию утилиты вроде compsize.

типичный базар. тут пришили - там отвалилось. мне понравилось, что в FreeBSD+ZFS этот вопрос решают системно.

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

FreeBSD мне тоже долгое время нравилась, однако пришлось таки признать её меньшую актуальность. Кстати, этот Zstd распространяется под лицензией BSD. Столлман наверняка будет недоволен, но Zstd теперь уже стандарт IETF RFC 8478.

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

Кстати, этот Zstd распространяется под лицензией BSD. Столлман наверняка будет недоволен, но Zstd теперь уже стандарт IETF RFC 8478.

Стандартом является не конкретная реализация.

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

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

AVL2 ★★★★★ ()

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

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

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

А есть какие-то другие, более подходящие реализации?

Не знаю, но ты можешь (нет) написать, порадовать дедушку Столлмана. Хотя его наверняка устроит GPLv2 у референсной.

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

Мне религиозные пристрастия последователей Столлмана неинтересны.

Столлман наверняка будет недоволен

А, узнаю стиль. Добавил в игнор.

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

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

Исполняемые файлы уже сжаты? А всякого рода логи и временные файлы?

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

Define «нормально».

Как в примере в моём комментарии.

Вот так это выглядит в Btrfs:

 % dd if=/dev/zero of=file bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1,1 GB, 1,0 GiB) copied, 0,306988 s, 3,5 GB/s
 % btrfs property set file compression zstd
 % btrfs filesystem defragment -r -czstd file
 % du file 
1,0G	file
 % du --apparent-size file 
1,0G	file

Это как угодно, но точно не нормально.

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

В случае сжатия нужно считать/записать меньше данных (т.е. потратить меньше времени). Но при этом потратить время на сжатие/разжатие данных. Очевидно от железа зависит кто кого сборет.

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

https://btrfs.wiki.kernel.org/index.php/Compression#Why_does_not_du_report_the_compressed_size.3F

Why does not du report the compressed size?

Traditionally the UNIX/Linux filesystems did not support compression and there was no item in stat data structure allocated for a similar purpose. There’s the file size, that denotes nominal file size independent of the actually allocated size on-disk. For that purpose, the stat.st_blocks item contains a value that corresponds to the number of blocks allocated, i.e. in case of sparse files. However, when a compression is involved, the actually allocated size may be smaller than nominal, although the file is not sparse. There are utilities that determine sparseness of a file by comparing the nominal and block-allocated size, this behaviour might cause bugs if st_blocks contained the amount after compression.

Another issue with backward compatibility is that up to now st_blocks always contains the uncompressed number of blocks. It’s unclear what would happen if there are files with mixed types of the value. The proposed solution is to add another special call for that (via ioctl), but this may be not the ideal solution.

hummer ()

Кроме того, ожидается прирост в производительности при чтении и записи.

На SATA и на последовательных операциях это наверное и так, но вот при случайном доступе и на nvme как бы обратное не вышло.

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

Думаю, что забесплатно протестить нечто на восторженных добровольцах Фейсбуку лишним не будет.

Откуда такое неприятие к тестам на добровольцах?

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

Это как угодно, но точно не нормально.

Это нормально.

То есть ты просто хочешь другую семантику st.i_blocks. Программы ожидают увидеть в st.i_blocks конкретное число (суммарный размер всех блоков, заполненных данными) и btrfs его предоставляет.

О каких костылях речь?

Забыл ответить на эту часть: compsize. Оно ещё и без повышенных привилегий не работает.

Интерфейс stat() не рассчитан на ФС с прозрачным сжатием. Костыль — это скорее то, что сделали в ZFS.

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

FB тут несколько непричем,
Yann Collett вначале сам разрабатывал, а потом его просто спонсировали, это мог сделать кто угодно, но ФБ успели первыми.
Первые версии zstd никакого упоминания фейсбука не несли.

Sylvia ★★★★★ ()