LINUX.ORG.RU
ФорумTalks

Почему в linux нет CompressedFS?


0

3

Намедни покурил архитектуру eCryptFS. Она работает как прозрачная крипто-прослойка. А для непосредственного хранения уже зашифрованных файлов использует другую ФС. Работает целиком в kernel-space. Это удобно и гибко, хоть и выглядит сложнее чем dmcrypt+[lvm]+fs. И вот я задумался о сабже.

Требуется сжато хранить хорошо сжимающиеся файлы на xfs/ext4/samba/любой-другой-фс, и чтоб иметь к ним простой rw-доступ без самописных костылей и толстых прослоек, пролегающих через юзерспейс. Чтоб это выглядело как работа с reiser4 compress=gzip.

Есть ли в ядре linux какие-либо предпосылки/проблемы, по которым СompressedFS наподобии ecryptfs не может быть реализована? Или может уже есть другие решения?

PS: btrfs/reiserfs не предлагать - одна инвалид детства, другая уже мертва. Userspace-поделия (fuse и др) не предлагать по понятным причинам.

★★★★★

Последнее исправление: shahid (всего исправлений: 2)

btrfs/reiserfs не предлагать

сам задал вопрос, сам ответил.

DNA_Seq ★★☆☆☆
()

Это удобно и гибко

И менее надёжно, чем dm-crypt. Или уже решены проблемы с работой поверх XFS? Баг с замусориванием файлов на ext4 наверно исправили…

GotF ★★★★★
()

Требуется сжато хранить хорошо сжимающиеся файлы на xfs/ext4/samba/любой-другой-фс

С списке рассылки ext4 когда-то обсуждалась такая возможность. Тед Тсо ответил, что если кто-то возьмется за это дело, то он ему поможет и вкратце описал как это можно сделать.

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

Squashfs, Cramfs

Рид-онли. Тем более, они нижнего уровня. В топике требуется layered file-system.

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

С списке рассылки ext4 когда-то обсуждалась такая возможность. Тед Тсо ответил, что если кто-то возьмется за это дело, то он ему поможет и вкратце описал как это можно сделать.

Опять получится non-unix-way велосипед... Хочется простенького ФС-независимого сжатия без fuse.

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

Опять получится non-unix-way велосипед... Хочется простенького ФС-независимого сжатия без fuse.

В принципе, идея интересная.

Вообще, в плане поддержки сжатия, выбор ФС невелик: http://en.wikipedia.org/wiki/Comparison_of_file_systems#Allocation_and_layout...

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

А как же NTFS?

fuse же. Тормозилово с тройным memcpy + gzip будет очень заметно грузить проц на больших файлах.

shahid ★★★★★
() автор топика

PS: btrfs/reiserfs не предлагать - одна инвалид детства, другая уже мертва. Userspace-поделия (fuse и др) не предлагать по понятным причинам.

Толсто же. Btrfs это лучшая ФС в истории человечества и пока даже в дали ей конкуренты не виднеются. Чем плох fuse с юзерспэйсом мне тоже не понятно.

bigfrogg
()

С сжатыми файлами слишком большие накладные расходы при операциях отличных от линейных чтения/записи.

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

Чем плох fuse с юзерспэйсом мне тоже не понятно.

>Тем, что не очень быстрый, например.

Думается мне что для fuse файловой системы с компрессией основные тормоза будут не в переходах kernel-user а в расчётах той самой компрессии. Так что в данном случае скорость kernelspace и userspace фс будет примерно одинаковой при остальных равных условиях.

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

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

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

Юзерспейс-ФС начнут однопоточно прыгать под 100% CPU ещё до начала разжатия при среднем/высоком i/o.

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

Насколько я знаю, это не взяли в ядро, так что, если чувствуешь в себе силы... :)

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