Ext4 и прозрачное сжатие директорий

решения через FUSE с монтированием ZIP-архивов

Вроде как других решений и нет, ext не поддерживает сжатие

попахивает глюками и дикими тормозами

Так ты попробуй, потом нам расскажешь))

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

Сделай еще один раздел с zfs рядом, полного переформатирования не будет, ваш КО)

На ZFS у тебя работает не только сжатие, но и архитектура файловой системы поддерживает дедупликацию благодаря COW (copy on write).

Т.е. когда на файловую систему записываются блоки данных она проверяет был ли блок с таким же хэшем или нет. Если бы - записывается ссылку на него.

На Ext4 ничего такого не получится, даже со сжатием.

На ZFS у тебя работает не только сжатие, но и архитектура файловой системы поддерживает дедупликацию благодаря COW (copy on write).

Дедуп выключен. Тут только сжатие.

На Ext4 ничего такого не получится, даже со сжатием.

Но меня интересует только сжатие.

А почему не zstd? Zstd сжимает хуже, но меньше грузит процессор и самая высокая скорость распаковки

А почему не zstd? Zstd сжимает хуже, но меньше грузит процессор и самая высокая скорость распаковки

Если ты притащишь мне поддержку сжатия в ext4 через zstd, я поставлю её.

Еще можно с… NTFS все сжимать (но я за Btrfs)

поддерживает дедупликацию

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

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

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

Просто дедуп на самом деле не то чтобы прямо очень часто нужен. В большинстве случаев простого сжатия достаточно.

без полного переформатирования диска

btrfs-convert

Ещё можно урезать раздел с ext4, создать раздел под базу данных в нужной фс и примонтировать в нужную папку.

что попахивает глюками и дикими тормозами

Насчёт глюков конечно разное бывает, но вот тормозами попахивают любые засовывания живой базы под сжатие (кроме случаев когда оно реализовано нативно в движке базы). А уж из-за 300G городить всё это ещё более странно.

btrfs-convert

Нет. Просто нет.

Насчёт глюков конечно разное бывает, но вот тормозами попахивают любые засовывания живой базы под сжатие

Лол у нас на бенчах тупо смена ext4 на zfs+lz4 увеличила производительность запросов почти в два раза. На одинаковом железе, одинаковой версии postgresql и так далее.

И судя по тому, что в среднем zfs без сжатия не шибко быстрее ext4, я прозреваю, что всё дело как раз в сжатии.

А уж из-за 300G городить всё это ещё более странно.

Схерали? Я за этот диск деньги плачу. Если я могу платить меньше денег либо использовать больше диска за те же деньги, нихера в этом странного нет.

Твоё экспертное мнение как и всегда экспертно.

Ну в базе 95% операций - это чтение обычно. С ZSTD еще больше будет, потому как она побыстрее распаковывается

zfs без сжатия не шибко быстрее ext4, я прозреваю, что всё дело как раз в сжатии.

Так может оно в кешах оперативки лежать поболее стало. Тогда сжатие для ext тебе тоже не поможет.

zfs без сжатия не шибко быстрее ext4, я прозреваю, что всё дело как раз в сжатии.

Так может оно в кешах оперативки лежать поболее стало. Тогда сжатие для ext тебе тоже не поможет.

Если у ext4 его нет, вот тогда точно не поможет. И судя по экспертным ответам, я прозреваю, что всё таки его нет.

без полного переформатирования диска

Будет изврат либо в виде двигания разделов, либо zfs в файле на ext4.

я прозреваю, что всё дело как раз в сжатии

Ну, если диски небыстрые, то при соотношении 70/300, конечно.

гугл показывает всякие странные решения через FUSE с монтированием ZIP-архивов, что попахивает глюками и дикими тормозами.

Тут новость проскакивала по новому ядру 6.9, так что может и не будет «глюков и диких тормозов»:

В подсистеме FUSE, применяемой для реализации файловых систем в пространстве пользователя, добавлена начальная реализация режима «passthrough», позволяющего напрямую на уровне ядра получать данные файлов, минуя процесс, работающий в пространстве пользователя, что позволяет в некоторых ситуациях существенно повысить производительность.

Zstd сжимает хуже, но меньше грузит процессор и самая высокая скорость распаковки

Всё ровно наоборот )
lz4 = lzss, zstd=lz+подобие хаффмана.

Будет изврат либо в виде двигания разделов, либо zfs в файле на ext4.

Чо? Ext4 позволяет ставить атрибуты отдельным директориям. Casefold так работает. Я надеялся на что-то похожее.

Ну, если диски небыстрые, то при соотношении 70/300, конечно.

Pcie 4.0. 4 гига чтение, 3 гига запись. Это по спекам.

Выглядит как стрельба в ногу. Зачем БД фс, сжатие и дедупликация? О_о

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

А почему не zstd? Zstd сжимает хуже, но меньше грузит процессор и самая высокая скорость распаковки

Потому что это плюс-минус золотой стандарт в сжимании фс/блочки.

Тут новость проскакивала по новому ядру6.9, так что может и не будет «глюков и диких тормозов»:

Ты не понял. Глюки будут не от FUSE, глюки будут от ZIP-архивов и от наверняка крайне убогой реализации этого костыля.

Ты правильно сделал, что поставил мне фейспалм выше. Ведь я пытался развить твою мысль из шапки темы, хотя это же абсолютно дикий костыль, как и твое желание заполучить из ext4 подобие zfs, btrfs или bcachefs.

Хочешь сжатия и экономии места, пользуйся соответствующими файловыми системами. Это самый простой путь. )

Pcie 4.0. 4 гига чтение, 3 гига запись

Даже для 4х действительно тормозные, но я думал, речь вообще о HDD )
Раз был такой прирост с zfsс этими дисками, думаю, скорее «виноват» агрессивный кэш.

Ты правильно сделал, что поставил мне фейспалм выше. Ведь я пытался развить твою мысль из шапки темы, хотя это же абсолютно дикий костыль, как и твое желание заполучить из ext4 подобие zfs, btrfs или bcachefs.

Подобием ZFS оно станет, когда в ext4 запилят volume manager. А прозрачное сжатие – так, сравнительно небольшая фича.

Даже для 4х действительно тормозные, но я думал, речь вообще о HDD )

PostgreSQL на HDD в 2024 году – это для очень сильных духом, которые ну вообще никуда не торопятся.

То ли дело на ssd добавить фс, сжатие и дедупликацию - вот где скорость)

ext4 не поддерживает сжатие на уровне ФС. Как бы для того разные ФС и существуют, что у них набор фич разных. Тебе нужна ФС с поддержкой сжатия. Например, ZFS, BTRFS или Bcachefs. Выбирай по вкусу. Если в ext4 добавить сжатие, она перестанет быть ext4. Собственно в этом её суть, что она проста по фичам и во многом благодаря этому стабильна.

Если переразметка диска по каким-то причинам не вариант, можно создать пустой файл нужного размера и применить на него mkfs.btrfs (или по вкусу). В линуксах не зря «всё файл», ФС можно создать и не на настоящем устройстве. Но, конечно, без прослойки в виде «лишней» ext4, нормально на разделе, будет несколько быстрее.

Кстати, а на уровне ДБ не проще будет сжатие включить?

Кстати, а на уровне ДБ не проще будет сжатие включить?

Постгрес АФАИК жмёт только те поля, что не влезают в страницу. А значит такого сжатия, как в ОП не будет. Плюс индексы.

Если в ext4 добавить сжатие, она перестанет быть ext4.

Почему? Casefold и древовидные директории (вместо связного списка лол) вот добавили, среди прочих фич, ext4 не перестала быть ext4 после этого.

Кстати, а на уровне ДБ не проще будет сжатие включить?

Его нет в PostgreSQL для любых данных, только для некоторых типов. И оно не сжимает, например, индексы. Если ты спрашиваешь, не проще ли мне будет добавить поддержку сжатия в PostgreSQL, то нет, не проще.

Почему? Casefold вот добавили, среди прочих фич, ext4 не перестала быть ext4 после этого.

Ну тут вопрос философский, конечно.

В любом случае, никто этого не сделал. Можешь попробовать добавить и пропихнуть в ядро. Только чую, что пропихнуть будет ещё сложнее, чем написать, собственно код (что уже задача не совсем тривиальная, учитывая устройство ext4).

Его нет в PostgreSQL для любых данных, только для некоторых типов.

А, точно. Забыл. Давно с PostgreSQL не работал, в последнее время приходится с MariaDB дела иметь (я её не выбирал, и там свои подводные, но это отдельная история).

Почему?

Потому что прозрачного сжатия без CoW/RoW (оно же «write anywhere») не бывает. А если в ext4 завезти CoW, она перестанет быть ext4 по очевидным причинам.

Потому что прозрачного сжатия без CoW/Write-Anywhere не бывает.

Почему? Где про это почитать? Почему в NTFS есть сжатие, но нет CoW?

Потому что прозрачного сжатия без CoW/RoW (оно же «write anywhere») не бывает. А если в ext4 завезти CoW, она перестанет быть ext4 по очевидным причинам.

Ну шифрование же завезли.

Если в ext4 добавить сжатие, она перестанет быть ext4

Однако ж в нее добавили шифрование (отнимает хлеб у LUKS ряяя и тормозит)

можно создать пустой файл нужного размера и применить на него mkfs.btrfs

А разве ext4 может создавать какие-то специальные файлы, чтобы напрямую на диск писать, минуя все эти файловые страницы и тп?

Почему? Где про это почитать?

Мозгами пораскинуть. Чтобы было прозрачное сжатие, тебе нужна атомарная работа с экстентами/блоками сильно больше дискового блока. А это либо CoW, либо журналирование всех данных (экв. data=journal). Второе предполагает ровно 2x падение производительности, поэтому никто в здравом уме делать так не будет.

Ну шифрование же завезли.

Совсем разные вещи.

Мозгами пораскинуть. Чтобы было прозрачное сжатие, тебе нужна атомарная работа с экстентами/блоками сильно больше дискового блока.

Тогда как в NTFS это работает? Причём там это было чуть ли не со времён NT 3.51.

Почему в NTFS есть сжатие

Потому что оно тупорылое и работает на 4K-блоках.

Почему в NTFS есть сжатие

Потому что оно тупорылое и работает на 4K-блоках.

И почему нельзя сделать опциональное тупорылое сжатие в ext4 таким же образом? Это всё ещё лучше, чем его полное отсутствие.

Совсем разные вещи.

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

Потому что оно тупорылое и работает на 4K-блоках.

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

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

Шифрование работает посекторно (и поэтому не предъявляет особых требований к атомарности записей), сжатие — нет.

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

Эм. Я не знаю, о каком окне ты говоришь, но и btrfs, и zfs сжимают блоками/экстентами по 16-64K.

Потому что с такими характеристиками оно нафиг никому не упёрлось.

+ строго говоря, с 4K-блоками тоже есть проблемы и это не объяснение. 4Kn-диски появились совсем-совсем недавно, а до этого нельзя гарантировать, что 4K запишутся атомарно. В общем, я не знаю, как в NTFS это решается. Возможно, журналированием данных, а возможно, на целостность просто хрен забили.

В btrfs по дефолту 16 килобайт, раньше 8 было, а еще ранее 4, но нельзя больше 64KiB. Я вручную 32 выставлял

Почему в NTFS есть сжатие

Потому что оно тупорылое и работает на 4K-блоках.

Вообще, нет. Оно там совсем не тупорылое.

Compression is enabled on a per-folder or per-file basis by setting the ‘compressed’ attribute. When compression is enabled on a folder, any files moved or saved to that folder will be automatically compressed using LZNT1 algorithm (a variant of LZ77).[65] The compression algorithm is designed to support cluster sizes of up to 4 KB; when the cluster size is greater than 4 KB on an NTFS volume, NTFS compression is not available.[66] Data is compressed in 16-cluster chunks (up to 64 KB in size); if the compression reduces 64 KB of data to 60 KB or less, NTFS treats the unneeded 4 KB pages like empty sparse file clusters—they are not written. This allows for reasonable random-access times as the OS merely has to follow the chain of fragments.

Это из педикивии.

Эм. Я не знаю, о каком окне ты говоришь, но и btrfs, и zfs сжимают блоками/экстентами по 16-64K.

И что мешает сделать то же самое в ext4? Выделить зону для записи, все попадающие туда данные сжимаются и только после этого пишутся экстенты. Никакого CoW не надо, тупо offline compression. Ну и нам все ещё ничего не мешает делать все то же самое во время сброса page cache, т.е. писать пожатые данные прямо в экстент.

А перезапись ты как собрался обрабатывать?