Почему заглохла разработка e2compr? FS со сжатием.

Функциональность нужная, простот она не нужна в Ext* при наличии Btrfs.

Ведь на ZFS придется переходить!

btrfs же :)

Ведь на ZFS придется переходить!

вариантов нет. btrfs - вечно допиливать будут.

наличии Btrfs

Походу, историй успеха с btr-ом в продакшн меньше, чем с ZFSonLinux. На лоре достаточно ZFSоводов, про бтрщиков не слышно

про бтрщиков не слышно

Фрактал.

Оно просто ещё сыровато для продакшена, все боятся. А десктопных бтрщиков полно на лоре.

Походу, историй успеха с btr-ом в продакшн меньше

хотелось бы услышать хоть одну

Я не в продакшене. Если нужен опыт какого-никакого продакшна - кастуйте erzent или как там его.

Неужели функциональность настолько ненужная?

а да, кстати, зачем нужно прозрачное сжатие на уровне файловой системы?

(цель — экономить место? или цель — убыстрить ввод\вывод и таким образом убыстрить работу системы?)

но сжатие ведь не бесплатное. тратит CPU. то есть — у тебя становится меньше ресурсов CPU для полезных дел :) ..

(таким образом: цель «убыстрение системы» — весьма спорно достигать этим методом)

я вот ,например, на BTRFS не использую сжатие.. (поэкспериментировал 1 денёк и всё..). хотя тут-на-ЛОР — некоторые люди отписывались что используют на BTRFS сжатие.

если у тебя медленный HDD — то советую тебе просто сделать его дефрагментацию (инструментарий вокруг BTRFS позволяет это). ну в смысле когда там много накопится файлов уже..

а да, кстати, зачем нужно прозрачное сжатие на уровне файловой системы?

это не для десктопа.

а почему бы и нет? Файлы разные бывают. Моя цель - экономия места на ssd заюзать ssd там, где об этом и не помышляли до этого, повысив производительность рандомной записи. Мои 2TB данные, сжатые gzip, занимают дай бог если 100GB. Было бы офигенно затюнить систему, добавив прослойку-сжатие над ssd.

я вот ,например, на BTRFS не использую сжатие

либо боишься, либо тебе не нужно - ответ прост. btrfs я, пожалуй, боюсь

Походу, историй успеха с btr-ом в продакшн меньше, чем с ZFSonLinux. На лоре достаточно ZFSоводов, про бтрщиков не слышно

эта ваша секта ZFS`щиков — очень громогласная, да..

то и дело слышу в форумных-постах активные попытки размножения — в стиле "поставь себе ZFS"..

ну а какой нормальный человек (кроме меня :)) станет хвастаться что у него на компе BTRFS? обычно её просто ставят (или BTRFS или EXT4) и дальше просто работают на компьютере. всё :)..

и точно также (как и BTRFS) — ни кто не хвастается файловой системой EXT4 :) .. а всё потому что и BTRFS и EXT4 — это просто обычные родные-и-обычные для Линуксов файловые системы..

а да, кстати, зачем нужно прозрачное сжатие на уровне файловой системы?

А почему бы нет? SSD же не резиновые.

но сжатие ведь не бесплатное. тратит CPU

На современных ЦП сжатие вообще незаметно - там десятые доли процента нагрузки.

Мои 2TB данные, сжатые gzip, занимают дай бог если 100GB. Было бы офигенно затюнить систему, добавив прослойку-сжатие над ssd.

в данном случае думаю — тебе помогло бы использование сочетания:

btrfs_subvolume + btrfs_сжатие

таким образом — можно было бы монтировать бы обычные файлы — как обыно. а особенный subvolume — в режиме сжатия.

На современных ЦП сжатие вообще незаметно - там десятые доли процента нагрузки.

всегда рядом с такими высказываниями нужно указывать алгоритм сжатия. У меня декомпрессия lzma2-default происходит с 18МБайт/с на 16 ядерном сервере. Потому что не умеет многопоточность - раз. И тяжелый алгоритм - два. Сжатие было быстрее, около 50МБайт/с, ибо юзало все ядра.

btrfs я, пожалуй, боюсь

ну это правильно.

так как все эти центосы живут прошлым временем — то можно сказать в их временном потоке — BTRFS ещё не успели придумать\отладить.

ок. может и займусь. centos 5 только мешает. что btr, что zfs там хрен воткнешь. А сервак важный

Кто ж в здравом уме станет использовать lzma для сжатия в ФС? Там обычно lzo используется.

Хрен с ним со сжатием, лучше бы снапшоты сделали. А то приходится с zfs или lvm сношаться

ну снапшоты lvm хотя бы есть и работают сносно. А сжатия нет :(

сношаться с zfs

кажется, придется вступить в ваши ряды

работают сносно

особенно когда в бэкапы надо закатать 30 томов, в каждый из которых ведется активная запись. )))

работают сносно

Не работают они сносно: надо создавать отдельный раздел, указывать его размер, и не дак б-г он переполнится, тогда кирдык снапшоту.

Неужели функциональность настолько ненужная?

По факту лучше всех сжимает reiser4. В остальных фс хорошо сжимать не позволяет алгоритмическая база. https://reiser4.wiki.kernel.org/images-reiser4/f/fb/Compilebench-0.6.pdf

про бтрщиков не слышно

Они восстанавливают данные, им не до лора.

Лучше бы хейтеры btrfs восстановили себе мозги.

Моя цель - экономия места на ssd заюзать ssd там, где об этом и не помышляли до этого, повысив производительность рандомной записи.

Во-первых, какая у вас модель SSD? Если там контроллер SandForce, то сжатие на уровне FS будет наидебильнейшей затеей, так как оно уже производится на уровне контроллера. Так же, прозрачное сжатие FS для SSD - идея в принципе сомнительная. Обычно оно применяется для ускорения операций чтения-записи в случае, когда носитель медленный, а процессор - быстрый. С SSD есть риск получить проседание производительности вместо увеличения.

Неужели функциональность настолько ненужная?

Да. Нафиг ненужная, т.к. hdd нынче копеечные по стоимости на 1Мб. Сжатие было актуально в середине-конце 90-х. Тогда и в досе и в другом оффтопике были решения для сжатых дисков (DoubleSpace, Stacker и т.п.). В linux были тогда разные прибамбасы - патчи на ядро (я тогда пользовался веткой 2.1 из-за всяких новых вкусностей), патчи на libc, которые подключались с LD_PRELOAD и прозрачно открывали gz архивы, пакеры для бинарников (upx)

Сейчас это всё не актуально т.к. и места много и скорость достаточная.

места много

Особенно на SSD, да.

современные процессоры молотят распаковску гораздо быстрее ssd, по-моему, особенно lzo какой-нибудь

скорость чтения, братюнь

скорость чтения, братюнь

И что скорость? Основной массив данных на моём винте - музыка и кино, которые при сжатии только замедлятся. Система кэшируется в памяти. Какой прирост я получу от сжатия? ~10-15% в лучшем случае - это всё ни о чём, RAID решает проблему гораздо эффективнее.

современные процессоры молотят распаковску гораздо быстрее ssd, по-моему, особенно lzo какой-нибудь

ХЗ, возможно, надо тестить. В любом случае, с HDD результат однозначен, с SSD - совсем нет.

Есть 2x intel 730 240GB ssd для raid1, 16 ядер 2.6GHz xeon (до-sandy-bridge поколение, не помню точно какое), 24GB RAM

По предварительному тестированию, на ssd производительности хватает с запасом. На hdd производительность упирается в io диска. (увидеть просто: система клиент-сервер, когда запустили на ssd - гигабитный канал стал забивать полностью, обмен пошел ощутимо быстрее. с хдд было намного медленней, раз в 10).

Но все данные (1.7 TB) туда не помещаются. Сжатые тупо в tar.gz они занимают 70GB. Отсюда захотел сжатие на ФС.

Основной массив данных на моём винте - музыка и кино

ты просто хомячок

У вас там просто один HDD, что ли? Может, проще RAID0/RAID10 зафигачить?