# Fusecompress или сжимающая файловая система

## lefsha

На сегодняшний день существуют несколько файловых систем позволяющих сжимать данные.

В частности таковыми являются JFS для AIX от IBM и ZFS от Sun. Одна из самых противоречивых и возьму на себя смелость одна из самых прогрессивных фаловых систем последнего времени собирается предложить в ближайшем будущем плагин для сжатия файлов по алгоритму LZO, считающимся одним из самых быстрых алгоритмов для сжатия данных. Как я пропустил название этой FS? - Но читатель думаю уже понял о чем речь?   :Wink: 

К сожалению по настоящее время нет сжимаемой файловой системы в Linux. Есть правда обещания Sun интегрировать свою систему в Linux, но пока ее там не видно. Да и наверняка займет это некоторый срок, пока строгие дяди из группы разработчиков ядра примут ее в основное дерево исходников. У одного товарища это так и не вышло несмотря на все прелести уже обозначенной системы...

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

Оказывается подобный подход позволяет не только сократить место занимаемое файлами, но и увеличить скорость передачи их от одного устройства к другому. В данном случае с или на жесткий диск. Для этого нам необходимо лишь, чтобы время сжатия и последующей передачи информации  было меньше, чем передача информации в исходном виде. Процесс сжатия, вообще говоря, сложный и предполагает огромное количество возможностей реализации. Однако одна из них, LZO представленная на  http://www.oberhumer.com/opensource/lzo/ на сегодняшний день представляет самую быструю возможность сжимать данные. Было бы разумно поэтому использовать ее для хранения файлов на диске. В частности, помимо текстовых данных, для этого отлично подходят такие наборы данных как коллекция portage или исходники ядра Linux. Можно разумеется пробовать для этих целей и другие данные.

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

В идеале, конечно, было бы неплохо иметь жесткий диск со своим процессором, который осуществляет данные операции. Но и мощности нынешних процессоров вполне позволяют справится с такими задачами. Все равно они более 90% простаивают без дела.

А поскольку интегированной системы сжимающей данные пока нет, можно попробовать свои силы с программой работающей в системе FUSE, представляющую собой набор средств для работы с файловыми системами в пространстве пользователя. Конечно, такая концепция имеет свои недостатки в контексте применения сжимающих файловых систем, но это всегда лучше чем ничего. Авторы программы: Milan Svoboda & Anders Aagaard. Большое спасибо им за труд.

И так приступим:

Прежде всего нам придется пересобрать ядро с поддержкой FUSE:

```

File systems  --->

<*> Filesystem in Userspace support

```

Конечно можно собрать FUSE так же и в виде модуля к ядру.

Далее нам понадобятся:

```

sys-fs/fuse

dev-util/subversion

```

После установки этих пакетов выполняем следующие действия:

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

```

mkdir /tmp/trunk

cd /tmp

```

скачиваем исходники:

```

svn checkout http://svn.berlios.de/svnroot/repos/fusecompress/trunk

cd trunk

```

собираем:

```

make release

cp fusecompress /sbin/fusecompress

```

А теперь можно попробовать сжать исходники ядра или дерево portage:

```

cd /usr

fusecompress -c lzo -o allow_other ./portage

touch *

```

Если теперь зайти в данный каталог то можно легко проверить

сколько места занимает файл на диске:

```

du -sh filename

```

Его исходный размер можно увидеть так:

```

du -sh --apparent-size filename

```

--

Руководство является модификацией

https://forums.gentoo.org/viewtopic-t-405996-highlight-fusecompress.html

----------

## 046

Прикольно  :Smile: 

Но в reiser4 должна быть такая штука. Там и директории будут сжаты, что в данной конфигурации не возможно  :Smile: 

----------

## fedukoff

УРРРАА, товарищи!!!

(Извините, не сдержался)   :Very Happy: 

----------

## lefsha

 *046 wrote:*   

> Прикольно 
> 
> Но в reiser4 должна быть такая штука. Там и директории будут сжаты, что в данной конфигурации не возможно 

 

Я пробовал поставить такое на reiser4, весь инет обыскал.

Нашел единственное, что можно создавать файловую систему с опцией ctail40,

якобы тогда файлы будут сжиматься. Но никакого сжатия увидеть не удалось.

Файлы упорно занимали столько же места сколько весили.

Хотя  даже в исходниках ядра в дир. плагины есть модуль compress,

но о нем не удалось найти ничего.  Даже на самой странице namesys.com

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

Здесь же по крайней мере работает, хотя и не в том смысле как в настоящей

файловой системе.

----------

## Laitr Keiows

В http://ru.gentoo-wiki.com хорошо бы это записать.

----------

## lefsha

Я прочитал это как gentoo-ruki...

 :Wink: 

... вперед.

----------

## viy

А в чем плюсы такой файловой системы?..

----------

## fank

на этом форуме есть пример использования squashfs для хранения /usr/portage

инетресно, сколько это счастие отъедает времени проца?

----------

## lefsha

 *fank wrote:*   

> на этом форуме есть пример использования squashfs для хранения /usr/portage
> 
> инетресно, сколько это счастие отъедает времени проца?

 

squashfs - файловая система только для чтения!

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

Потом снова создавать обновленную файловую систему...

Вы будете это делать?

Если же для данной системы использовать lzo сжатие, то 

сжимание данных незаметно вообще. Причем чем быстрее процессор

тем более незаметней.

----------

## lefsha

 *viy wrote:*   

> А в чем плюсы такой файловой системы?..

 

Хм. Кажется все было написано...

----------

## Balancer

 *viy wrote:*   

> А в чем плюсы такой файловой системы?..

 

Пример из практики. Есть переносной ноутбучный винт на 20Гб. Стояла NTFS со сжатием на весь диск. Было 1..2Гб свободного места (остальное - тексты, документы, фотки, коллекция инсталляшек). В связи с переходом на Linux десктопа на работе, пришлось сменить FS на винте на FAT32 (Captive тогда почти не жила, да и сейчас это, судя по отзывам, то ещё глюкало). После смены FS на винт не влезло около 5Гб данных.

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

----------

## kon

http://e2compr.sourceforge.net/

это не то, что вам нужно?

----------

## 046

 *viy wrote:*   

> А в чем плюсы такой файловой системы?..

  Именно этой или сжатия вообще?

Ну плюсы примерно одинаковые, повышение скорости работы.

Мощность процессоров уже сильно обогнала скорость накопителей. И сжимать перед записью (или разжимать после чтения) получается ощутимо быстрее.

Простой пример повышения производительности. Mysql сжимает индекс. В результате для прочтения индекса надо прочитать меньше блоков диска, и это даёт сильный прирост скорости выборки.

----------

## lefsha

 *kon wrote:*   

> http://e2compr.sourceforge.net/
> 
> это не то, что вам нужно?

 

Да. Неплохой вариант. Другое дело, что у меня таких разделов нет,

а так бы можно было б пользоваться.

----------

