Resilient file system (ReFS)

дохтур · 11-07-12 15:18:55

petrun пишет:

Сживать, быстрее чем писать-читать с платин. Отсюда и выигрываем.

Гарантировано во всех случаях только ЦПУ будет больше греться, а если данные плохо жмутся - ещё и "бесплатный" DoS обеспечен big_smile

дохтур · 11-07-12 17:18:54

petrun пишет:

А так же на диск будет меньше писатся. И быстрее соответсвенно.

Гарантированно - нет

petrun пишет:

То есть по вашему производительность архиватора сильно зависит от типа данных, которые он сжимает? Вот это новость.

Естественно cool

дохтур · 11-07-12 17:57:28

petrun пишет:

если не брать случаи "нули vs рандом", то это не так заметно.

Сначала "вот это новость", а теперь "не так заметно" big_smile Что дальше - будем подгонять реальность под задачу?

Особенно на простых алгоритмах .которые там и используются.

Это deflate простой? big_smile Нужно иметь очень крутые яйца, чтобы такое заявлять

petrun пишет:

А что-нибудь помимо ваших сомнительных гарантий?

Матчасть, рекомендую подучить

Редактировался дохтур (11-07-12 17:58:05)

дохтур · 11-07-12 18:23:31

Склеил исходники/бинарники проектов в tar-архив, после zip, скорость сжатия ~20Мб/c, скорость сжания уже получившегося архива ~13Мб/c -- вполе себе однозначные результаты, мне кажется cool

дохтур · 11-07-12 18:41:26

petrun пишет:

Это я уже слышал. Но таки почему?

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

petrun пишет:

А про скорость собственно дисков вы умолчали?

Скорость компрессии в моём случае значительно ниже скорости чтения/записи c диска, существенное влияние исключается

petrun пишет:

Относительно простой. Относительно lzma например.

Бгг, разница между deflate и lzma по сути - в последнем range-кодер вместо huffman, т.е. по сложности они сопоставимы, а декодер lzma даже проще, поэтому низачот cool

Добавлено спустя 01 мин 15 с:

petrun пишет:

Я обновил предыдущий пост, посмотрите.

Дохрена мусора, спасибо

дохтур · 11-07-12 23:45:41

petrun пишет:

Время user - почти равно. Спасибо за внимание.

Что для lzo (ещё в режиме быстрейшего сжатия небось?) "почти равно" (16%), то для deflate уже 53%, причём при задании более эффективного сжатия эти %% будут только расти, удивительно рядом cool

petrun пишет:

Ну дык вопрос в размере словаря.

Вопрос не в размере словаря, а в том, что приходится часто балансировать дерево поиска/смещений, учи матчасть

petrun пишет:

Я уж молчу про запись на сжатую ФС.

И правильно делаешь, т.к. это вообще не в тему

petrun пишет:

И ни одной цифры.

Выделено жирным в #132, всматривайся

Добавлено спустя 42 мин 35 с:
Ещё некоторыми тут игнорируется очевидный вариант просадки производительности, а именно: случайная запись в файл, т.е. когда чтобы записать пару байт сначала нужно распаковать целый блок (64к, к примеру), обновить данные, запаковать блок, т.е. вот вам улучшенный DoS на тарелочке big_smile

Добавлено спустя 48 мин 13 с:
А если в результате записи/обновления этих байт пережатый блок окажется больше по размеру, чем исходный - прийдётся выделять новый блок, который судя по всему будет расположен явно не за пережатым, т.е. получим ещё и фрагментацию как бонус big_smile

дохтур · 12-07-12 10:07:00

petrun пишет:

Какое сжатие применяется в ФС, по вашему?

lzo либо zlib

petrun пишет:

Бля, бла, бла. Как вы быстро перешли от "всегда" к конкретным ситуациям.

Какой такой "всегда"? Просто напомню, что я писал:

Гарантировано во всех случаях только ЦПУ будет больше греться

И это факт, в отличии от голословного

petrun пишет:

А так же на диск будет меньше писатся. И быстрее соответсвенно.

Т.к. если файл плохо жмётся - экономии места мы не получаем, зато расходуем время ЦПУ, т.е. превед DoS

дохтур · 12-07-12 10:24:15

petrun пишет:

Либо lzjb

"Спешите видеть завтра во всех FS страны!" big_smile

petrun пишет:

Эт верно. Но DOS мы никак не получим, все упрется в диск гораздо раньше.

Необязательно конкретно драйвером FS 100% съесть, для DoS достаточно, чтобы другому сервису(ам) остатка времени ЦПУ не хватило - и BTRFS думает об этом big_smile

petrun пишет:

А если жмется

Да, губу можно очень сильно раскатать big_smile

petrun пишет:

Как вы думаете, за каким хреном производители SSD используют аппаратное сжатие?

Чтобы убедить, что "скорость" важнее всего, в т.ч. надёжности

дохтур · 12-07-12 11:57:43

petrun пишет:

Как об стенку горох. Мало это будет занимат ьпроцессорного времени, на самом деле мало.

Да ну? smile Откуда ж тогда слив и где вообще цифры загрузки ЦПУ? Опять в альтернативную реальность с идеальными условиями проецируемся?

petrun пишет:

А как именно страдает надежность от этого?

Применительно к SSD по отношению к HDD вообщем

дохтур · 12-07-12 13:52:40

petrun пишет:

Где-то слив, где-то убедительная победа. Как оыбчно и бывает.

Таки признал объективную реальность? А ведь совсем недавно была только слепая вера "на диск будет меньше писатся. И быстрее соответсвенно" - прогресс, однако big_smile

petrun пишет:

Ну так возьмите и померейте, уважемый.

Слив засчитан cool

дохтур · 12-07-12 14:26:58

petrun пишет:

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

Я тоже могу написать: petrun неправ, а потом через какое-то время добавить "я ж имел ввиду не все возможные обстоятельства" -- аналогичный подход

Форум StopLinux

Объявление

#126 11-07-12 15:18:55

Re: Resilient file system (ReFS)

#127 11-07-12 17:18:54

Re: Resilient file system (ReFS)

#128 11-07-12 17:57:28

Re: Resilient file system (ReFS)

#129 11-07-12 18:23:31

Re: Resilient file system (ReFS)

#130 11-07-12 18:41:26

Re: Resilient file system (ReFS)

#131 11-07-12 23:45:41

Re: Resilient file system (ReFS)

#132 12-07-12 10:07:00

Re: Resilient file system (ReFS)

#133 12-07-12 10:24:15

Re: Resilient file system (ReFS)

#134 12-07-12 11:57:43

Re: Resilient file system (ReFS)

#135 12-07-12 13:52:40

Re: Resilient file system (ReFS)

#136 12-07-12 14:26:58

Re: Resilient file system (ReFS)

Подвал форума