Выкинь уже линакс и поставь OpenSolaris

Вы можете внятно объяснить, зачем вам это нужно? Нет денег на жесткий диск? Или, наоборот, куча денег на мощный компьютер, чтобы постоянно сжимать/расжимать данные на корне? Зачем дефрагментация? Вы содержите торрент-трекер? Я на своих трех с лишним терабайтах особо не замечаю падения производительности в связи с фрагментацией. Если очень хочется, можно периодически скидывать информацию на промежуточный винчестер, форматировать основной, и заливать ее обратно - отличная дефрагментация.

А вообще, честно говоря, вантузятники на ЛОРе уже достали...

btrfs. compression and defrag included.

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

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

Все операции над данными (распаковка после считывания блоков и обратная запаковка новых данных в блоки) в этом случае происходят исключительно силами CPU, и дисковая подсистема работает с меньшим потоком данных, чем если бы она работала с данными без сжатия.

Вы можете внятно объяснить, зачем вам это нужно?

Очевидно, разгрузить каналы I/O дисковой подсистемы при наличии достаточно производительного CPU.

куча денег на мощный компьютер, чтобы постоянно сжимать/расжимать данные на корне?

Я боюсь спросить, что для тебя мощный компьютер

что для тебя мощный компьютер

Три самых топовых nVidia'вских видеокарты, как минимум 32Гб оперативки, как минимум четыре хотя бы четырехъядерных процессора, raid-массив на пару десятков терабайт... В общем, то, что лет через 5 будет считаться дешевым компьютером для домохозяек.

Кстати, думаю, именно такие мощности и потребуются чтобы удовлетворить желание ТС. Потому что на обычном компьютере (2Гб оперативки, четырехъядерник) даже работа с самой некошерной ФС выливается в заметные тормоза. А уж что будет с ФС со сжатием и дефрагментацией «на лету»...

разгрузить каналы I/O дисковой подсистемы при наличии достаточно производительного CPU.

Не вижу смысла: жесткие диски сейчас достаточно быстрые, а вот процессоры дороговаты...

1) reiser4

2) squashfs - если корень read-only (только не сжимать в lzma)

3) ext2 с e2compr - если журналируемость не критична

про дефраг - пошшупай от Коливаса - на фс пофиг - есть куча переделанных версий - тот же shake сделан на основе коливасовского скрипта
правда от дефрагментации профита мало...

Никогда не дефрагментирую - ибо убивает винт.

а я ради интереса пару раз пробовал - будет ли профит?
ан нет - нет его (

Причем тут вантузятники или деньги на жесткий диск или мощный проц? Я поставил btrfs со сжатием на корень и хомяк, помимо уменьшения занимаемого места, выросла скорость чтения/записи и пофиг что проц чуть более нагружен, один хер он почти никогда не бывает загружен полностью

ставь btrfs и будет тебе счастие и не слушай пионеров которые будут ее обсирать.

Вы можете внятно объяснить, зачем вам это нужно?

В СССР у жёстких дисков головок нет?

В ~2 раза меньше считывает данных соответственно меньше тормозов, особо мощный компьютер на это не нужен.
Не замечаю падения производительности, кгхм, полагаю это уже константа. И не пробовал увеличивать, наверно? SSD они ета, дураки, зря делают.

Хочетцо

но боязно. А то они опять формат сменят? Да я и корень хочу, возможно придётся помучаться с ведром.

>Кстати, думаю, именно такие мощности и потребуются чтобы удовлетворить желание ТС

Ты будешь удивлён, но для этого хватит второго ядра на любом дерьмовом семпроне/силиронне, или любой проц с частотой выше ~2.5 гГц.

>жесткие диски сейчас достаточно быстрые
Боюсь вы просто счастливо не знаете что такой быстрый жёсткий диск.

>только не сжимать в lzma
почему же?

>Никогда не дефрагментирую - ибо убивает винт.
Я рыдал. А то что головкам потом приходится танцевать в 3-4 раза дальше&больше это не убивает винт?

btrfs

// тред не читал

Формат вроде уже заморожен. Ну и последнее изменение формата вроде как было не критично. А в чем проблема с корнем на btrfs? выносишь boot отдельно и все.

но для этого хватит второго ядра на любом дерьмовом семпроне/силиронне, или любой проц с частотой выше ~2.5 гГц.

Почему же тогда жутко тормозит ntfs-fuse даже на четырехъядернике?

Потому что месье любит извращения

Reiser4, если я всё правильно понял!

Компрессия в btrfs неэффективна из-за того, что дерево последней не обеспечивает плотную упаковку данных. Были даже тесты (причем от btrfs производителей), которые показывают, что btrfs с компрессией тормозит. А в reiser4 комрессия эффективна: на хорошо сжимаемых данных lzo алгоритм там даёт 25% выигрыш в производительности.

>Я рыдал

А зря..

reiser4

>Вы можете внятно объяснить, зачем вам это нужно? Нет денег на жесткий диск? Или, наоборот, куча денег на мощный компьютер, чтобы постоянно сжимать/расжимать данные на корне?

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

Если правда интересно, gzip1/lzo1 сжатие нынче осиливают даже китайские недоцпу.

>Компрессия в btrfs неэффективна из-за того, что дерево последней не обеспечивает плотную упаковку данных. Были даже тесты (причем от btrfs производителей), которые показывают, что btrfs с компрессией тормозит. А в reiser4 комрессия эффективна: на хорошо сжимаемых данных lzo алгоритм там даёт 25% выигрыш в производительности.

У меня есть опыт эксплуатации reiser4 и btrfs, обе с компрессией на ssd. В абсолютных цифрах все, возможно, и так, как вы говорите, но на деле с reiser4 наблюдаются мелкие лаги системы и более длительные фризы с большим iowait. С btrfs все как по маслу.

У ТС, кажется, вариантов кроме btrfs нет, но нужно помнить, что пока ремонтировать - нечем.

Ремонт не так существенно. Раздел /home отдельно, копия /etc уже есть, так что \то по сути добровольная работа тестером.
Сейчас вот с самым новым не rc ядром в ubuntu мучаюсь, кернел паник и всё тут - не находит корень при том же .config'e

файл прочитается конечно быстрее, но представим что это бинарник прилодения...

он ведь целиком не читается? ну не весь код нужен одновременно для работы/старта приложения...

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

или все не так суицидально, и всякие btrfs уже все эти моменты учитывают?

reiser4 + gzip, ставь и дрессируй

Что за вольные фантазии? А про кэш ФС мы «нечаянно» забыли?
2. А про кэш диска?
3. А про деление на блоки?

>что это бинарник прилодения...

он ведь целиком не читается?

Как раз читается целиком.

Что за вольные фантазии? А про кэш ФС мы «нечаянно» забыли?

Ну не хватает вот системе памяти и из кэша ФС вытеснили копию. Невоможная ситуация? Более чем возможная.

2. А про кэш диска?

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

3. А про деление на блоки?

Ну типа в btrfs же экстенты, а не блоки. Что, если файл одним экстентом на диске лежит, весь экстент будем распаковывать, если два последних байта понадобилось?

Знает кто-нибудь как сжатие в этой бтрфс работает?

NTFS.

Присоединяюсь, ставь, только потом о потерянных данных не плачь.

Каких ещё данных, читаем внимательно - ставлю на /

У него btrfs на хомяке.