Сравнение файловых систем

>Итого 63МБ/секунду - это явно больше hdparm'овских 55, не так ли? Да и по gkrellm видно, что после окончания работы dd данные продолжают лететь на диск еще несколько секунд.

Дык от этого же обращений к i/o не меньше. И тут скорее буфер, чем кэш.

Но всеже при нехватке скорости i/o, ее можно скомпенсировать сжатием. Например посмотрите на скорость модема при просмотре html. Часто по 12k бывает, при этом коннект 4k - значит упираемся не в скорость коннекта, а в скорость порта.

>> У меня внешний модем :-) если это модем для диалапа, а не adsl или кабельный - по барабану внешний он или внутренний

А вот что говорит сам Ганс Рейзер о компрессии:

http://kerneltrap.org/node/5654

One of the plugins that is in a race to be stable before 2.6.14 is the compression plugin. That will allow you to use half the space while increasing performance. Yes, increasing performance, because CPUs are powerful and compression algorithms are efficient these days, and if you halve your IO it is good for performance. One of the keys to making this true is that we only compress at the time we flush to disk, rather than with every write, and that means that if you have a hot set of files that fit into RAM, there is no performance loss because there is no compression going on.

Jeremy Andrews: You mention that you want to stabilize the compression plugin by 2.6.14. What is important about 2.6.14? Hans Reiser: Umh, anytime I can double performance and halve space usage, it is a priority for me and I want it now! ;-)

Я думаю, человек посвятивший десять лет разработки файловой системе должен понимать в этом больше нас.

> Я думаю, человек посвятивший десять лет разработки файловой системе должен понимать в этом больше нас.

У него долгов на двести тысяч, машина 89 г. выпуска и ходит он по Москве в шлепанцах на босу ногу. Как можно слушать такого человека?

>У него долгов на двести тысяч, машина 89 г. выпуска и ходит он по Москве в шлепанцах на босу ногу. Как можно слушать такого человека?

Правильно, давайте лучше спросим у Березовского :)

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

> Объясните мне какая связь между io и сжатием.

Прямая! Обычная ФС среди прочей информации о файле хранит в его метаданных таблицу распределения блоков файла по файловой системе. Для обычной ФС этот список представим в качестве массива - u_int32_t file_blocks[NN]. Причем колчество полезных байт в последнем блоке просто вычисляется как (filesize % fs_block_size)

В "сжатой" ФС карта распределения блоков по ФС имеет куда более сложную структуру: для каждого блока файла вы должны в метаданных указать номер блока файловой системы, в котором начинается соответвствующий логический блок файла, с какой позиции в этом блоке файловой системы начинаются пожатые данные, и какова длина эти сжатых данных (иначе вы не сможете понять, с какой позиции вам предстоит в это блок дописывать). За счет необходимости обслуживания одного только этого при потоковой записи использование процессора у вас подскочит раз примерно в пять - например, с 5 до 25% _только_ на обслуживание метаданных.

И еще это практически удваивает объем метаданных на файловой системе (для файловой системы с размером блока 4 килобайта поля начальной позиции и длины данных должны иметь как минимум по 12 бит + минимум 32 бита для номера блока, итого 56 бит метаданных на кадый блок файла, против 32-х для обычной ФС), и соответственно увеличивает объем записи в журнал ФС процентов этак на 75 (или нам теперь и журнал не нужен?).

Самое же неприятное в том, что для каждого блока данных вам необходимо предусмотреть возможность того, что он располагается в двух блоках файловой системы - например если вдруг получится, что кто-то попытается писать на "сжимаемую" ФС архив bzip2, то вам периодически необходимо будет отмечать, что "порядковый блок номер 32 в этом файле занимает 138-й блок файловой системы с 39-го по 4095-й байты и 139-й блок файловой системы, с 0-го по 46-й байты", либо предусмотреть флажок "блок не сжимается".

Или вы понадеетесь что такого не будет и запишете в README "мы написали крутую ФС но она коредампится и теряет данные если они плохо сжимаются"?

Понимаете, на сжатии очень много подводных камней - и далеко не все они видны для того, кто считает, что hdparm вытесняет данные из кэша.

Уважаемая Даша. Я только что написал прогу реализующую мою идею. Она делает всю работу быстрее cp на 8-10сек быстрее, загружая проц на 90%. ЧТД. Ваши отмазки читать даже не стал.

> Я только что написал прогу реализующую мою идею.

Заколебал блин уже. Объясняю - перед ФС стоит задача не только потокового чтения и потоковой записи - идеи "один длумает, другой пишет" уже до тебя реализовали десятки раз - в том числе и в ядре, и в разных СУБД.

Тот же Oracle - они типа такие глупые, что до сжатия не додумались? А ведь у них как раз такая схема - все процессы ставят изменения в очередь, и специально выделенные процессы ввода-вывода их по диску распихивают. Более того у них - есть специальные журналы, куда данные только добавляются! И что самое смешное, оракловцы в один голос говорят - не вздумайте помещать журналы на всякие "сжатые тома"! Только RAID, желательно 0+1

Но пришел анонимус и открыл всем Истину :-)

> Но всеже при нехватке скорости i/o, ее можно скомпенсировать сжатием. Например посмотрите на скорость модема при просмотре html. Часто по 12k бывает

У меня при закачке mp3 по модему иногда 17 килобайт в секунду wget и scp показывают :-) Вот только я знаю об асинхронности TCP, а ты нет.

>Заколебал блин уже. Объясняю - перед ФС стоит задача не только потокового чтения и потоковой записи - идеи "один длумает, другой пишет" уже до тебя реализовали десятки раз - в том числе и в ядре, и в разных СУБД.

<censored>, сейчас матом ругаться начну. Тогда какого <censored> мы здесь пиписьками мерялись? Кто доказывал что его пиписька всегда будет длиннее(или короче)? А когда вам показали заоптимизированую пипиську, то вы стали говорить что мол она не той формы, не там растет, не так пахнет, не того цвета и что в квадратную жопу уж точно не пролезет...

> > Заколебал блин уже. Объясняю - перед ФС стоит задача не только потокового чтения и потоковой записи - идеи "один длумает, другой пишет" уже до тебя реализовали десятки раз - в том числе и в ядре, и в разных СУБД.

> <censored>, сейчас матом ругаться начну. Тогда какого <censored> мы здесь пиписьками мерялись?

А того, что все эти реализации используются на системах, для которых критична высокая производительность I/O (в тех же СУБД - и Informix, и Oracle, и полагаю что и DB/2 такая фича есть), в ядре та же XFS. Вот только что забавно - все они НЕ используют сжатия.

Думаешь от недостатка ума разработчиков?

Ты тут бросался фразами про модем: ты в курсе, что у потока данных, идущих по модему нет команды seek? Как, кстати, и у TCP-соединения. Сжатие красиво ложится на последовательное чтение или запись - но файловой системе еще нужен и случайный доступ.

Даже в твоем примере - пишешь ты tiff, многослойный - записал слой, вернулся в заголовок, подправил - скакнул в конец файла, дописал еще один слой, вернулся к началу, подправил заголовок... И все - вот тебе и уже и произвольный доступ. Он нужен.

> Я думаю, человек посвятивший десять лет разработки файловой системе должен понимать в этом больше нас.

Есть только одна тонкость: ФС версии 4, разработанную этим человеком, предпочитают не включать ядро. Люди, у которых опыта ещё больше :)

> Уважаемая Даша. Я только что написал прогу реализующую мою идею. Она делает всю работу быстрее cp на 8-10сек быстрее, загружая проц на 90%.

Будем обогревать комнату длинными холодными зимними вечерами? :)

>Ты тут бросался фразами про модем: ты в курсе, что у потока данных, идущих по модему нет команды seek?

извините, что встреваю, но вы, no-dashi, слишком категоричны, ИМХО:) А вы В КУРСЕ, что сжимаемость/несжимаемость файла/каталога МОЖНО (И НУЖНО) выставлять ТОЛЬКО для КОНКРЕТНО указханного файла/каталога? и что выставляя этот атрибут, нужно знать КАК его выставлять и ДЛЯ ЧЕГО? Ваши же заявления наталкивают на мысль, что сжатие вы представляете только в виде "на раздел". И "не позволять" админу/продвинутому пользователб сделать В НЕКОТОРЫХ СЛУЧАЯХ, ОСОЗНАННО комманду `chattr c file|dir` - это, как бы сказать помягче... снобизм, что ли?:) Такое ощущение, что параметр "с" вам просто мешает жить:)

Без обид, плиз - это скорее вопрос к вам, чем утверждение:)

>> Внимание вопрос: что запишется быстрее файл в 120mb >> или тотже файл сжимаемые на лету (в памяти) 60mb?

>Не люблю пустословие - давайте предоставим слово цифрам и тестам?...

>На всех тестах со сжатием цифры показывают, что попытка сжать данные для уменьшения I/O привела не к повышению производительности за счет двукратного уменьшения объема записываемых данных, а напротви, привела к двукратному падению производительности, причем система была вынуждена отдать все ресурсы на обслуживание процесса записи, то есть если бы у меня параллельно какая-нибудь орфография проверялась в большом документе, картина была бы еще хуже.

>Это цифры - они врать не способны.

>Видишь ли, ты прочел, пожал и записал в своем тесте данные за 55 секунд. Я без сжатия прочел и записал 636 метров за 31 секунду. Те же 700 метров отработаются менее чем за за 35 секунд. ГДЕ выигрыш от сжатия?!...

>> Эй, разве мы не упустили кое-что. Ведь если на выходе 2 файла 500Мб и 700Мб и быстрее был записан 2й >Нет, не упустили. Мы просто получили итог - полезный I/O без сжатия выше чем со сжатием, и только. Не важен процент загрузки I/O - важна _полезная_ пропускная способность: 700МБ за минуту (11.5 МБ/сек) со сжатием против 700МБ за 35 секунд (20МБ/сек) без сжатия. Это называется "чистая победа в итоговой производительности".

Я вам показал что прога у вас кривая, и что данные запишутся быстрее, поэтому все вышенаписанное ложь и не имеет права претендовать на объективность. И запишутся данные за время равное только записи данных, и время на упаковку приплюсовывать не надо. Вы сами этот тест затеяли. Хватит звездеть и отмазываться. Толку от ваших знаний 0, тк применить их вовремя вы не способны. Вы упустили, а я заметил что полезный io выше с сжатием, и 700Мб в нашем случае запишутся быстрее, и добился я этого именно за счет повышения процента загрузки io. А на то что кто-то где-то что-то не использует мне глубоко фиолетово.

>ФС версии 4, разработанную этим человеком, предпочитают не включать ядро. Люди, у которых опыта ещё больше :)

Я надеюсь, GNOME вы честно ненавидите?:) А не боитесь, что вас побьют "гномофилы-антирейзеровцы"? или "гномофобы-рейзерофилы"? Шутка:)

>Будем обогревать комнату длинными холодными зимними вечерами? :)

Не, пусть "интелофилы" с лениным обогревают - мы люди бедные, поэтому выбираем не "брэнд", а то, что по соотношению стоимость/производительность повыгоднее, обходимся:) И iPod'ы, и золотые телевозоры не покупаем ("шоб круто было") - так, iRiver'ами и серийными Hitachi перебиваемся, "бедные":)

>> Уважаемая Даша. Я только что написал прогу реализующую мою идею. Она делает всю работу быстрее cp на 8-10сек быстрее, загружая проц на 90%.

>Будем обогревать комнату длинными холодными зимними вечерами? :)

90% я получил от очень кривой реализации наскоро состряпаной на коленках, думаю можно и до 60-70% опустить на моем старом гигагерцовом celeron'e.

> Не, пусть "интелофилы" с лениным обогревают - мы люди бедные, поэтому выбираем не "брэнд", а то, что по соотношению стоимость/производительность повыгоднее, обходимся:)

А я это написал безотносительно к intel или amd. У amd тоже не все процы довольствуются 89 W. Я смогу найти процессору лучшее применение, чем бессмысленное сжатие/разжатие данных. А уж про ноутбуки вообще молчу: тут ФС с компримированием только и ждали. А то аккумуляторы последнее время работают недопустимо долго. Пора их подсадить, правда? :)

> И iPod'ы, и золотые телевозоры не покупаем ("шоб круто было") - так, iRiver'ами и серийными Hitachi перебиваемся, "бедные":)

А у тебя iPod есть? :)

> 90% я получил от очень кривой реализации наскоро состряпаной на коленках, думаю можно и до 60-70% опустить на моем старом гигагерцовом celeron'e.

Когда будет 10..20%, тогда можно будет серьёзно задуматься. Пока же овчинка выделки в большинстве случаев просто не стОит :)

Я ещё в начале-середине 90-х увлекался всякими drivespace/doublespace под DOS/Win3.x, но то было только от желания "увеличить" винт. Работало, к слову, вполне стабильно и даже на трёшках/четвёрках не так сильно тормозило. Но сейчас особого смысла не вижу.

> А вы В КУРСЕ, что сжимаемость/несжимаемость файла/каталога МОЖНО
> (И НУЖНО) выставлять ТОЛЬКО для КОНКРЕТНО указханного файла/каталога?

Предложите для каких файлов со сжатием стоит связываться.
GIMP'овские swap'ы? Ну-ну:

$ ls -l gimpswap*
-rw-------  1 test test 394919936 Янв 11 09:01 gimpswap.10958
-rw-------  1 test test 349585199 Янв 11 09:00 gimpswap.10958.lzo
$ rm gimpswap.10958.lzo 
$ time lzop gimpswap.10958 
real    0m37.609s
user    0m18.933s <---- Это время _только_ сжатия, без I/O
sys     0m2.120s
$ time cp gimpswap.10958 gimpswap.10958.def
real    0m16.590s <---- А это время собственно голого I/O
user    0m0.080s
sys     0m1.596s

Оно же пишется быстрее, чем жмется, при 50% использовании процессора
(который нужен для реальной работы, блин!) а выигрыш в размере составляет менее пятнадцати процентов!

Всякие вроде бы хорошо сжимаемые DBF'ы жать нельзя - на них постоянно
делается seek и update, нередко в середине файла. Всякое raw-видео и
звук имеет примерно 15% коэффициент сжатия (а использование процессора
мы уже видели - 50% времеени в user!). Большая часть графических
форматов уже имеет сжатие в своей спецификации, и даже OpenOffice
выдает сжатые PDF'ки. ГДЕ ниша "сжатия ради скорости", блин?!

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

Впрочем, никто вас не держит - исходники есть, компиляторы бесплатны.
Пишите, можете даже продавать (вон Veritas свой foundation за бабки
продает - и типа берут). Если все будет так шоколадно - у вас ваш
продукт с руками оторвут.

> поэтому выбираем не "брэнд", а то, что по соотношению стоимость/производительность повыгоднее, обходимся:)

Правильно. И сейчас это - Intel. AMD обнаглели в конец.

>Оно же пишется быстрее, чем жмется, при 50% использовании процессора (который нужен для реальной работы, блин!) а выигрыш в размере составляет менее пятнадцати процентов!

Да выкиньте вы свои кривые тесты к чертовой бабушке. Ваши разве самые правильные и других быть не может?

time ./lzop dragonfly.iso real 0m24.519s user 0m6.216s sys 0m2.024s ls -l dragonfly.iso* -rw-r--r-- 1 resident resident 230072320 Jan 9 23:50 dragonfly.iso -rw-r--r-- 1 resident resident 109819455 Jan 9 23:50 dragonfly.iso.lzo

time lzop suse10-cd1.iso real 1m36.797s user 0m37.954s sys 0m9.221s ls -l suse10-cd1.iso* -rw-r--r-- 1 resident resident 732893184 Jan 11 10:42 suse10-cd1.iso -rw-r--r-- 1 resident resident 717990313 Jan 11 10:42 suse10-cd1.iso.lzo

а это 2 нити: time ./compress dragonfly.iso dragonfly.iso.lzo real 0m15.607s user 0m12.189s sys 0m2.520s ls -l dragonfly.iso* -rw-r--r-- 1 resident resident 230072320 Jan 9 23:50 dragonfly.iso -rw-r--r-- 1 resident resident 106306872 Jan 11 10:57 dragonfly.iso.lzo

time ./compress suse10-cd1.iso suse10-cd1.iso.lzo real 1m50.060s user 1m37.390s sys 0m8.469s ls -l suse10-cd1.iso* -rw-r--r-- 1 resident resident 732893184 Jan 11 10:42 suse10-cd1.iso -rw-r--r-- 1 resident resident 521135352 Jan 11 11:02 suse10-cd1.iso.lzo

Во втором варианте в середине файла сжатие уперлось в процессор. lzop эти данные просто выплевывал, а мой пытался переживать. Те сжатие в определенных местах можно понижать и повышать.

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

Все, лучше нервы поберегу.

>Когда будет 10..20%, тогда можно будет серьёзно задуматься. Пока же овчинка выделки в большинстве случаев просто не стОит :)

С каких это пор скорость процессора приоритет #1 на десктопе? Какова средняя загрузка проца на среднем десктопе? Поставьте себе веник в 2 раза медленнее и будет вам не 50% а 25%.

Каша получилась.

time ./lzop dragonfly.iso
real    0m24.519s
user    0m6.216s
sys     0m2.024s

ls -l dragonfly.iso*
-rw-r--r--  1 resident resident 230072320 Jan  9 23:50 dragonfly.iso
-rw-r--r--  1 resident resident 109819455 Jan  9 23:50 dragonfly.iso.lzo

time lzop suse10-cd1.iso
real    1m36.797s
user    0m37.954s
sys     0m9.221s

ls -l suse10-cd1.iso*
-rw-r--r--  1 resident resident 732893184 Jan 11 10:42 suse10-cd1.iso
-rw-r--r--  1 resident resident 717990313 Jan 11 10:42 suse10-cd1.iso.lzo


а это 2 нити:
time ./compress dragonfly.iso dragonfly.iso.lzo
real    0m15.607s
user 0m12.189s
sys 0m2.520s

ls -l dragonfly.iso*
-rw-r--r--  1 resident resident 230072320 Jan  9 23:50 dragonfly.iso
-rw-r--r--  1 resident resident 106306872 Jan 11 10:57 dragonfly.iso.lzo

time ./compress suse10-cd1.iso suse10-cd1.iso.lzo
real    1m50.060s
user    1m37.390s
sys     0m8.469s

ls -l suse10-cd1.iso*
-rw-r--r--  1 resident resident 732893184 Jan 11 10:42 suse10-cd1.iso
-rw-r--r--  1 resident resident 521135352 Jan 11 11:02 suse10-cd1.iso.lzo

> С каких это пор скорость процессора приоритет #1 на десктопе?

С тех пор, когда на десктопе появились игрушки, которые периодически автосохраняются или грузят что-то с диска. Далее, я люблю смотреть видео в окне, параллельно что-то делая. Не хочу, чтобы оно при этом заикалось. Позиция "десктоп - орудие чайника, которому процессор всё равно не нужен" неприемлема.

> Какова средняя загрузка проца на среднем десктопе?

Такова же, какова средняя температура по больнице. Нельзя о вероятности сгорания проца судить по его СРЕДНЕЙ температуре - юзер загрузит его на 100%, и хана тому процу. Так и здесь.

> Поставьте себе веник в 2 раза медленнее и будет вам не 50% а 25%.

Я надеюсь, это Вы бредили просто?

>Я, честно говоря, уже хочу вернуть всё с reiser3'a на ext3

Аналогично :( У меня даже vogical volume с музыкой/фильмами на рейзере...

>Угу. В газетах развенчивают, но вот bonnie++ упрямо коронует обратно.

А чем, в сущности, то, что проделывает bonnie++, отличается от описанных в статье операций?

>интересно где он щас по дефолту не включен? dma

В Knoppix 4.0 :)

>А уж про ноутбуки вообще молчу: тут ФС с компримированием только и ждали. А то аккумуляторы последнее время работают недопустимо долго.

Тут ещё нужно определиться: если для вас "что-то" тяжелее 2 кг - ноутбук, то мне даже говорить с вами о "ноутбуках" неинтересно:)

>> И iPod'ы, и золотые телевозоры не покупаем ("шоб круто было") - так, iRiver'ами и серийными Hitachi перебиваемся, "бедные":)

>А у тебя iPod есть? :)

А внимателнее читать?:) "И iPod'ы, и золотые телевозоры НЕ покупаем...":)

> Да выкиньте вы свои кривые тесты к чертовой бабушке.
> Ваши разве самые правильные и других быть не может?

Вот только не надо отмазываться про кривые тесты, а? Ты начал про "меньше вывода на диск, поэтому быстрее" - я тебе цифры показал. Выяснилось, что не быстрее. Ты ринулся гнать про то, что типа не для всего нужно сжатие и начал распинаться про эффективность сжатия для всяких фотошопов и корелов - тебе было в лоб показано, что тот же самый GIMP'овский свап отвратительно жмется. При этом я еще не напомнил, что этот свап используется наиболее активно именно в момент проведения изменения - то есть в тот момент, когда процессор нужен, ты предлагешь его еще и сжатием подгрузить?

> а это 2 нити:
> time ./compress dragonfly.iso dragonfly.iso.lzo
> real 0m15.607s
> user 0m12.189s
> sys 0m2.520s
> ls -l dragonfly.iso*
> -rw-r--r-- 1 resident resident 230072320 Jan 9 23:50 dragonfly.iso
> -rw-r--r-- 1 resident resident 106306872 Jan 11 10:57 dragonfly.iso.lzo

А, держите меня трое, у меня истерика... Блин, тебе уж десять раз сказали - сжатие не успевает за дисковым выводом.

$ time { cp dragonfly.iso dragonfly.iso.nolzo ; sync ; }
real 0m10.542s
user 0m0.072s
sys 0m1.876s
$ ls -l dragonfly.iso dragonfly.iso.nolzo
-rw-rw-r-- 1 dalth dalth 230072320 Мар 11 19:02 dragonfly.iso
-rw-rw-r-- 1 dalth dalth 230072320 Мар 11 19:39 dragonfly.iso.nolzo

Ладно, фиг с ним - с маленьким файлом. Возьмем большой? Возьмем!

> time ./compress suse10-cd1.iso suse10-cd1.iso.lzo
> real 1m50.060s
> user 1m37.390s
> sys 0m8.469s
> ls -l suse10-cd1.iso*
> -rw-r--r-- 1 resident resident 732893184 Jan 11 10:42 suse10-cd1.iso
> -rw-r--r-- 1 resident resident 521135352 Jan 11 11:02 suse10-cd1.iso.lzo

$ time { cp /opt/dist/fc3/fc3d1.iso xx ; sync; }
real 0m31.144s
user 0m0.220s
sys 0m4.564s
$ ls -l fc3d1.iso xx
-rw-r--r-- 1 dalth dalth 646987776 Мар 11 19:56 fc3d1.iso
-rw-r--r-- 1 dalth dalth 646987776 Мар 11 19:57 xx

Трехкратное(!) отставание в производительности, причем в тесте голого I/O, где по твоим словам сжатие должно рвать всех нафиг! Это уже смешно, не находишь? Чем более "продвинутые" методы ты пытаешься использовать, тем худшие результаты ты получаешь. Кстати, посмотри внимательно на результат простого lzop, который ты делал сам:

> time lzop suse10-cd1.iso
> real 1m36.797s

Даже простой по твоим словам "неэффективный" lzop отработал на четверть быстрее чем твоя "продвинутая" методика. У ядра множество механизмов повышения производительности - всякие очереди, кэши, элеваторы, планировщики I/O - и они все адаптированы на то, чтобы минимизировать простои приложений. Процессор с гораздо большей пользой поищет свободный блок для записи данных вместо того, чтобы сэкономить мифическе 30% объема данных, а впоследствии элеватор переупорядочит блоки в очереди так, чтобы они записались за один проход головки HDD, и все будет замечательно.

> Поставьте себе веник в 2 раза медленнее и будет вам не 50% а 25%

Аргументы закончились? Этот винт два года в эксплуатации, а модель вообще середины 2003-го года, и через год его вообще можно будет смело юзать как большую дискетку (только в USB-обертку завернуть).

>Предложите для каких файлов со сжатием стоит связываться. GIMP'овские swap'ы? Ну-ну:

При чем тут "GIMP'овские swap'ы"? Как пример подходят любые заведомо несжатые файлы которые читаются последовательно и (возможно) дописыватся только в конец или переписываются (любые text-подобные файлы редактируемые в vim и читаемые httpd, xml/html/sgml/TeX/etc парсерами, распакованные для правки и сборки src (на чём угодно) - это только то что "навскидку" пришло в голову).

>Всякие вроде бы хорошо сжимаемые DBF'ы жать нельзя - на них постоянно делается seek и update, нередко в середине файла.

Тут не в DBF дело, а в любых файлах DB - они, как правило, действительно с произвольним доступом на чтение/запись - для них компрессия нежелательна. Хотя и из этого правила есть исключения: например, логи в DB, где запись идет только в "хвост", а чтение - не факт, что на сжатом будет медленнее выборка (зависит от размера файла, количество свободной памяти под кэш и т.п.)

>Всякое raw-видео и звук имеет примерно 15% коэффициент сжатия (а использование процессора мы уже видели - 50% времеени в user!)

мультимедия - согласен, даже не предлагаю их сжымать LZO:) Хотя и хранить их в RAW ИМХО неразумно - лучше уж сразу на лету жать lossless кодеком в какой-нибудь контейнер:)

>Большая часть графических форматов уже имеет сжатие в своей спецификации, и даже OpenOffice выдает сжатые PDF'ки.

И с этим не спорю:)

>>поэтому выбираем не "брэнд", а то, что по соотношению стоимость/производительность повыгоднее, обходимся:)

>Правильно. И сейчас это - Intel. AMD обнаглели в конец.

Как только наступит "сейчас" - так сразу и куплю "от Интел":)))

> Тут ещё нужно определиться: если для вас "что-то" тяжелее 2 кг - ноутбук, то мне даже говорить с вами о "ноутбуках" неинтересно:)

Да, и правда. Если для Вас основной критерий при выборе ноутбука - его вес... то для меня Вы, простите, как автолюбтельница, на вопрос "какой у вас автомобиль" отвечающая "красный" :) Производители, которых я знаю, в кратких характеристиках перечисляют совсем другое. Хотя бы Sony: http://www.sonystyle.com/is-bin/INTERSHOP.enfinity/eCS/Store/en/-/USD/SY_Brow...

Кстати, такую странную классификацию "если вес больше 2,8 (подставить своё значение) кг - то уже не ноутбук" я встречал только в России. Производители ноутбуков о таком полёте мысли даже не подозревают и продолжают называть даже тяжёлые 17''-модели ноутбуками. То ли Россия в области теории, как всегда, впереди планеты всей, то ли рахит в ней прогрессирует сильнее, чем мне казалось.

> А внимателнее читать?:) "И iPod'ы, и золотые телевозоры НЕ покупаем...":)

То есть нету? А вообще mp3-player есть?

И правда, не покупаю я iPod'ы. Мне бы функциональность, а не понты. Мой iRiver послужил мне верой и правдой, а полгода назад я его сплавил родственникам. У них он продолжает работать и вполне им нравится. Я себе другой покупать не стал вообще - неохота.

Телевизоры? Золотые? А что, это в Москве сейчас новый тренд? Не слыхал :) Что, рекомендуете приобрести? :)

> Хотя и из этого правила есть исключения: например, логи в DB

Только не говорит этого ораклистам - загрызут в момент :-)

> любые text-подобные файлы редактируемые в vim и читаемые httpd, xml/html/sgml/TeX/etc парсерами, распакованные для правки и сборки src

Почти попали, вот только одно но - конфиги текстовые считываются, как правило, один раз при старте программы. Исходники? Опять немного неудачный пример. Их объем во-первых весьма небольшой, то есть будь он хоть сжат, хоть не сжат - все равно за один оборот "блина" считается. И процессор жалко - компилятор, как известно, штука чрезвычайно процессороемкая, и сжатие опять "в пролете" :-) TeX также процессор любит - нам в университете курс TeX'а читали, и хоть я его успещно прогулял, но помню таки разницу межды компиляцией теховского документика в DVI'шку на 486 и на P100 - она была ну очень ощутима. Всяким веб-серверам процессор тоже необходим - кто всякие перлы/жабы/ппыхыпы выполняет?

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

> А вообще mp3-player есть?

Кстати да - какой смысл в нем? На работе все равно одевать наушники -0 я же не админ какой - по этажам бегать? Да и звук получше, и не приходится раздражать коллег, у которых вкусы другие. По дороге на работу / с работы вообще дрыхну - два часа сна лишними не бывают. Дома? Жена обидится - "ты меня совсем не слушаешь!"

Так что mp3-плееры - для джоггеров и иже с ними :-)

>Вот только не надо отмазываться про кривые тесты, а? Ты начал про "меньше вывода на диск, поэтому быстрее" - я тебе цифры показал. Выяснилось, что не быстрее.

Да задавись же ты нафиг, вот что МОЙ cp показывает. До вас еще не дошло что вы с совершенно другим анонимусом говорили?

time { cp dragonfly.iso nnn; sync; }

real 0m26.356s user 0m0.092s sys 0m2.328s

time { cp suse10-cd1.iso mmm; sync; }

real 1m0.388s user 0m0.236s sys 0m7.460s

Еще раз говорю что во втором варианте я уперся в процессор и io простаивало, а в первом нет(можете даже списать 2 сек на погрешность, но это ничего не изменит). Если бы моя прога работала как lzop то скопировала бы SuSe быстрее на 20Мб т.к. lzop не упирается в процессор. Разве не видно что разные данные сжимаются с разной скоростью? Достаточно дать функции сжатия определенное время на работу и, если она не успеет, то писать данные в несжатом виде или не ждать запаздывающий блок, а изменить их порядок или сперва производить оценку сложности сжатия.

>> С каких это пор скорость процессора приоритет #1 на десктопе?

>С тех пор, когда на десктопе появились игрушки, которые периодически автосохраняются или грузят что-то с диска. Далее, я люблю смотреть видео в окне, параллельно что-то делая. Не хочу, чтобы оно при этом заикалось. Позиция "десктоп - орудие чайника, которому процессор всё равно не нужен" неприемлема.

Ооооооо, ну куда уж нам отсталым до "продвинутых" геймеров с их "чисто десктопными" приложениями. Для кваки сжатие, явно, самое то будет. В мане так и напишем: "Всем геймерам обязательно выставить флаг сжатия на папке Games и убиться об стену". Идите ка лучше и почитайте Таненбаума?

> вот что МОЙ cp показывает.
> time { cp suse10-cd1.iso mmm; sync; }
> real 1m0.388s
> user 0m0.236s
> sys 0m7.460s

Некорректный тест. В тесте со своим compress'ом ты не делал sync.

> а это 2 нити:
> time ./compress suse10-cd1.iso suse10-cd1.iso.lzo
> real 1m50.060s
> user 1m37.390s
> sys 0m8.469s

И что мы видим? Со сжатием копировали две минуты. Без сжатия за 1 минуту. В упор не вижу преимуществ сжатия - использование процессора выше, суммарная пропускная способность ниже.

> Еще раз говорю что во втором варианте я уперся в процессор и io простаивало

Пофиг кто и почему простаивает - надо чтобы копирование файла быстрей закончилось. Либо ты показываешь пример с объективно более высокой производительностью, либо в бобруйск.

>Некорректный тест. В тесте со своим compress'ом ты не делал sync.

>> Еще раз говорю что во втором варианте я уперся в процессор и io простаивало >Пофиг кто и почему простаивает - надо чтобы копирование файла быстрей закончилось. Либо ты показываешь пример с объективно более высокой производительностью, либо в бобруйск. Да задавитесь вы своим гребаным sync'ом, ну ведь знаете что не произойдет чуда:

time { ./compress dragonfly.iso dragonfly.iso.lzo } real 0m19.831s user 0m15.473s sys 0m2.768s

Ну получилось +4 сек, 20сек с компрессией против 26сек без нее. Что не так? Чем не объективный пример?

Неее, я уже начинаю сомневаться в ваших умственных способностях. Если IO загружено на 100%, то что быстрее: прочитать 200Мб и записать 200Мб или прочитать 200Мб и записать 100Мб? А если 100% IO - 200Мб - 200Мб и 50% IO - 200Мб - 100Мб? Так вот, образно выражаясь, у меня во втором тесте во время этих гребаных 50% IO процессор жмет плохоужимаемые данные, вместо того чтобы их писать, растрачивая тем самым драгоценное IO, а в первом эти данные быстроужимаемые, и он не думает, а пишет используя IO на всю катушку. Победа будет только в одном случае: ОПЕРАЦИИ ВВОДА/ВЫВОДА ПРИ КОПИРОВАНИИ ФАЙЛА НЕ ДОЛЖНЫ ОСТАНАВЛИВАТЬСЯ, ПРОЦЕССОР ЖЕ ДОЛЖЕН ПОСТАРАТЬСЯ СОКРАТИТЬ ИХ КОЛИЧЕСТВО.

При копировании половина времени тратится на чтение 200Мб, а вторая на запись 200Мб. В первом случае сжатие составляет 50% значит половина времени уйдет на чтение 200Мб, а на запись только 100Мб экономя 25% времени:

time { cp dragonfly_x2 aa; sync; } <- файл в 2 раза увеличен для наглядности превосходства

real    0m43.956s
user    0m0.092s
sys     0m4.548s

time { ./compress dragonfly_x2 bb; sync; }

real    0m31.551s
user    0m25.138s
sys     0m4.872s

Во сколько бы раз я не увеличил этот файл везде будет +25% скорости и -50% размер.

> time { cp dragonfly_x2 aa; sync; }

Ты на сузешном образе это покажи.

>> Хотя и из этого правила есть исключения: например, логи в DB

>Только не говорит этого ораклистам - загрызут в момент :-)

Ораклисты-фанатики, которые даже тривиальные логи в OracleDB пишут - мне не указ:)

>Почти попали, вот только одно но - конфиги текстовые считываются, как правило, один раз при старте программы.

Я про конфиги как раз не упоминал, но раз уж вы начали:) "Почти попали": 1) далеко не все СИСТЕМНЫЕ конфиги читаются один раз при старте системы (см. smb.conf, конфы и скрипты hotplug, etc); 2) далеко не всё в /etc - системные конфиги; 3) далеко не все программы, чьи конфиги в /etc - запускаются и при этом читают свой конфиг олин раз за сеанс работы на ПК; 4) даже однократная загрузка конфигов уж как минимум не ухудшит скорость загрузки. Так что про конфиги у вас - в основном, "в молоко" - лучше бы не говорили о них:)

>Исходники? Опять немного неудачный пример. Их объем во-первых весьма небольшой

Небольшие? Ну не знаю... Разверните исходники kernel, xorg-x11, mozilla, да много чего еще...

>И процессор жалко - компилятор, как известно, штука чрезвычайно процессороемкая, и сжатие опять "в пролете"

А вы проверьте загрузку процессора при компиляции тех же xorg, kernel прежде чем такое заявлять. Hint: я проверял - AFAIR 20-50% на 2GHz CPU.

>TeX также процессор любит - нам в университете курс TeX'а читали, и хоть я его успещно прогулял, но помню таки разницу межды компиляцией теховского документика в DVI'шку на 486 и на P100 - она была ну очень ощутима.

А я не предлагаю категорически dvi сжимать (хотя можно проверить-попробовать). Я вобще основное преимущество вижу на файлах, которые значительно чаще читаются, чем дописываются.

>Всяким веб-серверам процессор тоже необходим - кто всякие перлы/жабы/ппыхыпы выполняет?

1) Есть ещё и статические HTML (обычные или сформированные и закешированные) - забыли? 2) "всякие перлы/жабы/ппыхыпы" не просто "выполняет", а ещё и парсит соотв. интерпретатор, здесь записи практически нет если кеширования динамического контента нет, а если и есть - lzo не слишком "напряжный" алгоритм для процессора:)

>Вот для какого-нибудь бардачка файлового сжатие бы подошло - но то только ради экономии дискового пространства

1) перечисленное мною - и есть "бардачок файловый" по большому счёту:) 2) Экономия дискового пространства - всё что угодно, но уж никак не "минус" ко всему прочему (повышению производительности В НЕКОТОРЫХ СЛУЧАЯХ, и ТОЛЬКО КОГДА Я ЯВНО И ОСОЗНАННО УКАЖУ ЧТО И ГДЕ СЖИМАТЬ!).

>Кстати да - какой смысл в нем?

Не большой, но есть:) К тому же в нём ещё и радио есть - телевизор я почти не смотрю, а в курсе новостей неплохо бы быть (новости из инета - не предлагать плиз - я хочу ПРОСТО новости, а не чей-то взгляд на них:)).

>По дороге на работу / с работы вообще дрыхну - два часа сна лишними не бывают.

У меня полчаса, поспать не получается:) Сейчас у меня mp3-плейера тоже уже нет, вернее мне хватает оного в КПК, при том, что ещё и книжку можно почитать:)

>Дома? Жена обидится - "ты меня совсем не слушаешь!"

Дома вобще ИМХО глупо с mp3-плейером ходить - лучше стационарную систему включить:)

>Так что mp3-плееры - для джоггеров и иже с ними :-)

Опять же - слишком категорично ИМХО. Они не являются предметом первой необходимости, но в некоторых случаях не мешают:)

>А вообще mp3-player есть?

Был. Есть и сейчас, но не совсем MP3-плейер, а КПК выпоняющий его функция (наряду с другими):)

>> time { cp dragonfly_x2 aa; sync; } 

>Ты на сузешном образе это покажи.

Все, собирайтесь на вокзал за билетом до Бобруйска. Вот вам
переписаный архиватор, делающий работу без простоев:

time { ./compress suse10-cd1.iso suse10-cd1.iso.lzo; sync; }

real    1m1.732s
user    0m45.107s
sys     0m11.657s

ls -l dragonfly_x2.iso*
-rw-r--r--  1 resident     resident     732893184 Jan 12 11:03 suse10-cd1.iso
-rw-r--r--  1 resident     resident     725271736 Jan 12 12:42 suse10-cd1.iso.lzo <- lzop жмет до 718Мб, но это можно списать на
неоптимальность моего алгоритма, dragonfly же стал жаться быстрее,
за 15-18сек с sync'om, но размер только -35%.

Было у меня и архивирование за 55сек и копирование за 1.10сек и lzop
за 1.50сек. Но и бобру понятно, что при компрессии 1-2% данные
примерно эквивалентны тк погрешность явно больше, но жать данные
ради 2% никто и не собирается.

>ls -l dragonfly_x2.iso*
ls -l suse10-cd1.iso*

> но вот на разделе с данными мне нужно чтобы файлы с названиями extreme - god isn't dead?.ogg создавались без проблем

Я аж чуть не поперхнулся ....

ak@ak-laptop:~$ touch extreme\ -\ god\ isn\'t\ dead?.ogg
ak@ak-laptop:~$ ls -l extreme*
-rw-r--r--  1 ak ak 0 2006-01-12 16:53 extreme - god isn't dead?.ogg
ak@ak-laptop:~$ rm -f extreme\ -\ god\ isn\'t\ dead\?.ogg
ak@ak-laptop:~$ mount
/dev/hda2 on / type reiserfs (rw,notail)
...

слив засчитан ?

Кстати, любителя annie lennox это тоже касается:
ak@ak-laptop:~$ touch annie\ lennox\ -\ no\ more\ \"i\ love\ you\'s\".ogg
ak@ak-laptop:~$ ls -l annie*
-rw-r--r--  1 ak ak 0 2006-01-12 16:54 annie lennox - no more "i love you's".ogg
ak@ak-laptop:~$ rm -f annie\ lennox\ -\ no\ more\ \"i\ love\ you\'s\".ogg

> Вот вам переписаный архиватор, делающий работу без простоев:
> time { ./compress suse10-cd1.iso suse10-cd1.iso.lzo; sync; }
> real 1m1.732s
> user 0m45.107s
> sys 0m11.657s

Замечательно. Теперь у тебя в квартире лето и пальмы цветут, а кот греется в потоках тепла от процессора?

Ты снова изображаешь из себя глухого. Того, что ты сотворил, _недостаточно_ для файловой системы. Посмотри в /usr/linux/include/fs.h - там есть структура file_operations - в ней первым полем описывается функция llseek. Как ты ее реализуешь?

Или хотя-бы аналог dd if=suse10-cd1.iso of=xxx skip=100000 bs=10000 ты как реализушь для сжатого файла с приемлемой производительностью? Или еще хлеще - tail -c 30 your_compressed_file_name, чтобы далеко не ходить. Чтобы не мучаться с примерами - даже тривиальнейшее добавление данных в конец файла как реализовывать будешь?

То что ты сейчас тут старательно показываешь, никому не интересно, и на порядок красивее реализовано в isofs/zisofs. Но если ты прочтешь man mkisofs и код isofs, то увидишь какие ухищрения требуются, чтобы все это нормально работало и реализовывало все функции, потребные от файловой системы.

>Того, что ты сотворил, _недостаточно_ для файловой системы.

Это верно - нужно смотреть в сторону http://sorceforge.net/projects/e2compr например

>на порядок красивее реализовано в isofs/zisofs

Здесь проще - только чтение:)

> > Исходники? Опять немного неудачный пример. Их объем во-первых весьма небольшой

> Небольшие? Ну не знаю... Разверните исходники kernel, xorg-x11, mozilla, да много чего еще...

Ядро собирается порядка 20 минут (с нуля) при том, что весит около 200 мегабайт. Соответственно, реальный I/O там 10 мегабайт в минуту - 180 килобайт в секунду :-)

> далеко не все СИСТЕМНЫЕ конфиги читаются один раз при старте системы (см. smb.conf, конфы и скрипты hotplug, etc)

$ ls -l /etc/samba/smb.conf -rw-r--r-- 1 root root 698 Дек 4 23:13 /etc/samba/smb.conf

Огромная экономия (у меня размер блока 4К :-)). Вместо одного блока мы прочтем один блок, но зато со сжатием :-) И не говорите про sendmail.cf в 80 килобайт - как раз он читается один раз, и перечитывается только по SIGHUP :-) всякие скрипты hotplug? time cp -R /etc/hotplug* /etc/udev* /tmp => real 0m0.077s Ужас!!! Это такое замедление! :-)

> Есть ещё и статические HTML (обычные или сформированные и закешированные) - забыли?

А не лучше ли под mod_deflate процессор запользовать? И за трафик меньше платить, кстати. И если уж идет упор в дисковый I/O - всегда есть squid в режиме http accelerator - он в разы эффективней.