LINUX.ORG.RU

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

 , e2compr, , ,


0

1

Неужели функциональность настолько ненужная? Имеется в виду прозрачное сжатие файлов на уровне ФС. Может я плохо искал, и есть прослойка, типа mdadm для создания сжатого блочного девайса поверх диска или типа того?

Ведь на ZFS придется переходить! А в centos его нет из коробки :( Попутал, в epel есть: http://zfsonlinux.org/epel.html (про centos 5 пока не понятно, соберется ли)

Deleted

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

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

btrfs же :)

vurdalak ★★★★★
()

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

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

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

наличии Btrfs

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

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

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

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

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

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

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

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

pedobear
()

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

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

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

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

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

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

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

user_id_68054 ★★★★★
()
Последнее исправление: user_id_68054 (всего исправлений: 6)
Ответ на: комментарий от user_id_68054

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

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

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

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

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

Deleted
()
Последнее исправление: Deleted (всего исправлений: 3)
Ответ на: комментарий от Deleted

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

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

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

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

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

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

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

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

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

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

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

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

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

btrfs_subvolume + btrfs_сжатие

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

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

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

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

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

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

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

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

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

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

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

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

pedobear
()

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

xorik ★★★★★
()
Последнее исправление: xorik (всего исправлений: 1)
Ответ на: комментарий от xorik

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

сношаться с zfs

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

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

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

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

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

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

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

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

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

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

Axon ★★★★★
()

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

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

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

no-such-file ★★★★★
()
Ответ на: комментарий от Axon

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

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

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

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

no-such-file ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

Есть 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. Отсюда захотел сжатие на ФС.

Deleted
()
Ответ на: комментарий от no-such-file

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

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

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

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

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