Resilient file system (ReFS)

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

petrun пишет:

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

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

petrun · 11-07-12 16:06:35

дохтур пишет:

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

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

дохтур пишет:

а если данные плохо жмутся - ещё и "бесплатный" DoS обеспечен

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

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

petrun пишет:

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

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

petrun пишет:

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

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

petrun · 11-07-12 16:43:40

дохтур пишет:

Естественно

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

% dd if=/dev/urandom of=./random bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 195.751 s, 5.4 MB/s
% dd if=/dev/zero of=./zeros bs=1M count=1000 
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 24.7048 s, 42.4 MB/s
% echo 3 | sudo tee /proc/sys/vm/drop_caches 
Password: 
3
% time lzop random
zsh: correct 'lzop' to 'lzip' [nyae]? n
lzop: random.lzo: already exists; not overwritten
lzop random  0.00s user 0.00s system 1% cpu 0.225 total
<1> % rehash 
% rm random.lzo 
% rm zeros.lzo 
% time lzop random
lzop random  2.96s user 1.59s system 7% cpu 57.506 total
% time lzop zeros 
lzop zeros  2.55s user 0.27s system 12% cpu 22.049 total

дохтур пишет:

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

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

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

petrun пишет:

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

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

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

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

petrun пишет:

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

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

Отредактировано дохтур (11-07-12 16:58:05)

wr224 · 11-07-12 17:22:11

дохтур пишет:

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

У луноходов и с шифрованием тоже самое, поэтому они шифруют все что можно, цпу вытянет wink

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

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

petrun · 11-07-12 17:26:57

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

дохтур пишет:

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

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

дохтур пишет:

вполе себе однозначные результаты, мне кажется

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

дохтур пишет:

Нужно иметь очень крутые яйца, чтобы такое заявлять

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

wr224 · 11-07-12 17:39:01

petrun пишет:

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

А про то, что это требует много памяти, ты скромно умолчал

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

petrun пишет:

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

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

petrun пишет:

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

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

petrun пишет:

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

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

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

petrun пишет:

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

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

petrun · 11-07-12 18:28:06

дохтур пишет:

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

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

дохтур пишет:

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

Ну дык вопрос в размере словаря. Я уж молчу про запись на сжатую ФС.

дохтур пишет:

Скорость компрессии в моём случае значительно

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

Добавлено спустя 21 с:

wr224 пишет:

А про то, что это требует много памяти, ты скромно умолчал

Это, это что?

wr224 · 11-07-12 22:24:22

petrun пишет:

Это, это что?

Архивация, не трудно догадаться

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

petrun пишет:

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

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

petrun пишет:

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

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

petrun пишет:

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

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

petrun пишет:

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

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

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

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

petrun · 12-07-12 07:59:59

дохтур пишет:

Что для lzo (ещё в режиме быстрейшего сжатия небось?)

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

дохтур пишет:

Ещё некоторыми тут игнорируется очевидный вариант просадки производительности, а именно: случайная запись в файл

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

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

petrun пишет:

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

lzo либо zlib

petrun пишет:

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

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

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

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

petrun пишет:

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

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

petrun · 12-07-12 09:13:39

дохтур пишет:

lzo либо zlib

Либо lzjb
denisy.dyndns.org/lzo_vs_lzjb/

дохтур пишет:

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

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

Как вы думаете, за каким хреном производители SSD используют аппаратное сжатие?
SSD с большим физическим рамером болка для этого удобна.

MOP3E · 12-07-12 09:22:57

petrun пишет:

Как вы думаете, за каким хреном производители SSD используют аппаратное сжатие?
SSD с большим физическим рамером болка для этого удобна.

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

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

petrun пишет:

Либо lzjb

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

petrun пишет:

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

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

petrun пишет:

А если жмется

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

petrun пишет:

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

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

petrun · 12-07-12 09:54:54

дохтур пишет:

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

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

дохтур пишет:

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

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

MOP3E пишет:

ощутимо сэкономит место.

На ssd? Это что, размер диска больше станет? ж)

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

petrun пишет:

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

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

petrun пишет:

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

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

petrun · 12-07-12 11:34:50

дохтур пишет:

Да ну? smile Откуда ж тогда слив

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

дохтур пишет:

и где вообще цифры загрузки ЦПУ?

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

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

petrun пишет:

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

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

petrun пишет:

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

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

petrun · 12-07-12 13:05:49

дохтур пишет:

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

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

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

petrun пишет:

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

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

petrun · 12-07-12 13:28:32

дохтур пишет:

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

Разумный подход. Неужели фраза "так быстрее" для вас значит "так всегда быстрее"?

Форум StopLinux

Объявление

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

Re: Resilient file system (ReFS)

#127 11-07-12 16:06:35

Re: Resilient file system (ReFS)

#128 11-07-12 16:18:54

Re: Resilient file system (ReFS)

#129 11-07-12 16:43:40

Re: Resilient file system (ReFS)

#130 11-07-12 16:57:28

Re: Resilient file system (ReFS)

#131 11-07-12 17:22:11

Re: Resilient file system (ReFS)

#132 11-07-12 17:23:31

Re: Resilient file system (ReFS)

#133 11-07-12 17:26:57

Re: Resilient file system (ReFS)

#134 11-07-12 17:39:01

Re: Resilient file system (ReFS)

#135 11-07-12 17:41:26

Re: Resilient file system (ReFS)

#136 11-07-12 18:28:06

Re: Resilient file system (ReFS)

#137 11-07-12 22:24:22

Re: Resilient file system (ReFS)

#138 11-07-12 22:45:41

Re: Resilient file system (ReFS)

#139 12-07-12 07:59:59

Re: Resilient file system (ReFS)

#140 12-07-12 09:07:00

Re: Resilient file system (ReFS)

#141 12-07-12 09:13:39

Re: Resilient file system (ReFS)

#142 12-07-12 09:22:57

Re: Resilient file system (ReFS)

#143 12-07-12 09:24:15

Re: Resilient file system (ReFS)

#144 12-07-12 09:54:54

Re: Resilient file system (ReFS)

#145 12-07-12 10:57:43

Re: Resilient file system (ReFS)

#146 12-07-12 11:34:50

Re: Resilient file system (ReFS)

#147 12-07-12 12:52:40

Re: Resilient file system (ReFS)

#148 12-07-12 13:05:49

Re: Resilient file system (ReFS)

#149 12-07-12 13:26:58

Re: Resilient file system (ReFS)

#150 12-07-12 13:28:32

Re: Resilient file system (ReFS)

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