RheaVFS — прямой доступ к содержимому архивов

> домашнее заданее - узнать, что значит буква "U" в слове "fuse". потом начинать "аналлизировать" новость заново

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

Любопытная вещь... Но думаю, что все же надежнее будет распаковать архив, да и скорость доступа к таким "каталогам" не будет выше, чем распаковка архива, наверное. Кто-нибудь уже опробовал сабж?

Любопытная вещь... Но думаю, что все же надежнее будет распаковать архив, да и скорость доступа к таким "каталогам" не будет выше, чем распаковка архива, наверное. Кто-нибудь уже опробовал сабж?

> Имхо, сжатие должно быть фичей или модулем ФС, и выполняться > прозрачно для софта. Неудобно, когда почти весь /usr/share/doc/ > пожат gzip'ом (автораспаковка в vim/gimp/... есть кучка велосипедов/ > костылей).

как например tarfs? :) http://www.freebsd.org/news/status/report-2007-04-2007-06.html#tarfs:-A-tar-F...

как например tarfs? :)

Нет не так. FUSE давно уже позволяет _монтировать_ десятки типов файлов (а не только tar) и легко добавлять поддержку новых. Сейчас речь идет о _прозрачном доступе_ -- т.е. без mount

> Сейчас речь идет о _прозрачном доступе_ -- т.е. без mount

Тогда это поделка, нафик не нужная.

Чушь. По трудозатратам, что распакавать архив, что подмонтировать. Здесь же можно прямо указать имя компонента опуская один этап. Кроме, того он находится в естественном месте, а не в какой-то левой точке монтирования.

> потому, что tar - ___tape___ архивер. то есть, во времена оны, нужно было всё равно перемотать ленту до нужного места.

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

Теперь и в Линуксе можно будет залить на форум архив, зайти в него как в архив, и выполнить произвольный код на машине через багу в архиваторе. :-)

Или залить zip на форум и доставать оттуда картинки и HTML-ки как из каталога.

Или залить tar с cgi-ками и правом на исполнение скриптов.

Или DOS-ить файловый сервер.

Или играть в игру "угадай тип архива".

Короче, больше проблем хороших и разных на самом базовом уровне системы!

Просто вместо 10 разных слоев VFS (mc, gnome, kde, oo...) можно будет использовать один. Что проще в отладке. И безопасной. Потому, что флаг noexec будет устанавливаться в одном месте и администратором, а не в ста и пользователем.

Это общий момент. Если какие-то потенциально опасные функции не реализуются на базовом уровне, то возникает сотня костылей с десятками дыр.

Я тоже не тащусь от предложенного синтаксиса. Но именно для обеспечения безопасности системы это правильный шаг.

И еще. Мне кажется, что написать программу позволющую извлекать файлы из .tar.{gz.bz2} архива без полной декомпрессии можно. Не просто. Но можно. Средние коэффициенты сжатия известны. Плюс немного эвристики...

Может быть проще всё-таки разработать новый тип архива?

>> Имхо, сжатие должно быть фичей или модулем ФС, и выполняться прозрачно для софта. Неудобно, когда почти весь /usr/share/doc/ пожат gzip'ом (автораспаковка в vim/gimp/... есть кучка велосипедов/костылей).
а при копировании будет распаковка - запаковка снова ? + копирования в 10 раз большей информации ? ну ну

>>Создайте мне файл "." без кавычек. Или ".."

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

Любопытная функциональность.. Я полагаю, в любом случае, не помешает..

> а при копировании будет распаковка - запаковка снова ?

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

> + копирования в 10 раз большей информации ? ну ну

Запакованые данные читаются с диска, а распакованые копируются из памяти в память.

ну мы же копируем не в пределах диска ?
и даже не в пределах одной физической машины ?
и ресурсы у нас очень ограничены ?
и мы не хотим сжимать несжимаемые данные ?
слишком много И получается :) для десктопа это возможно эффективно
для серверов / задач работающщих с большими объёмами информации - нет
либо потребует весьма тонкой настройки

> ресурсы у нас очень ограничены ?

ну вот, вечно не хватает этих ресурсов, и это при общепризнаной недогруженности процессоров на серверах :) При желании процессор можно избавить от компрессии, навесив последнюю на соответствующую (PCI) карточку.

> и мы не хотим сжимать несжимаемые данные ?

можно подобрать несложную эвристику, которая будет правильно распознавать сжимаемтость 80-90% от общей массы данных.

> для десктопа это возможно эффективно для серверов / задач работающщих c большими объёмами информации - нет

Это, скорее, психологические преграды :) Есть работающие решения, можете проверить их эффективность для больших объемов информации.