The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Rad Hat развивает новую ФС NVFS для NVM-памяти, opennews (?), 18-Сен-20, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


5. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"  +3 +/
Сообщение от Аноним (5), 18-Сен-20, 23:44 
для таких хранилок лучше сжимать в zstd, ибо распаковка не будет замедлена (но места станет больше).
Ответить | Правка | Наверх | Cообщить модератору

8. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"  +/
Сообщение от Аноним (8), 18-Сен-20, 23:55 
Zstd топчик, на сильном сжатии он даже может обходить lzma без вопросов, но всё ещё быстрее. А главное распаковка быстрая -- у lzma распаковка адово тормозная, хуже lzma только bz2.
Ответить | Правка | Наверх | Cообщить модератору

15. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"  +/
Сообщение от б.б. (?), 19-Сен-20, 00:48 
процитирую себя

===========
мобильный ryzen 5 2500

zstd --ultra -22 = 16 сек, xz -9 = 12 сек. при этом xz пожал лучше. один файл, конечно, не показатель


zstd -9 1.4 сек, итоговый файл 10.4 мб. gzip -9 - 6.6 сек, итоговый файл 11.1 мб
=========

вообще, на чём я пробовал, zstd --ultra был медленнее xz, и жал хуже

Ответить | Правка | Наверх | Cообщить модератору

21. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"  +/
Сообщение от Аноним (8), 19-Сен-20, 01:42 
Ну такое, да. В прошлый раз, zstd был быстрее (разница доходила до 15%), и файлы меньше выдавал (примерно на 0.5%), но там другие, менее скучные датасеты были. Равноценно, в принципе. Зато распаковка быстрее.

===
префикс вайна
===
zstd-22:.wine-64
real    4m24.891s
user    10m11.530s
sys     0m7.929s
-rw-r--r-- 1 anon anon 416M Sep 19 01:10 winedrive.tzst
xz-9:.wine-64
real    4m12.598s
user    13m13.847s
sys     0m6.941s
-rw-r--r-- 1 anon anon 413M Sep 19 01:20 winedrive.txz
===
пара текстовых файлов
===
zstd-22:txtdata
real    1m31.187s
user    1m30.307s
sys     0m0.657s
-rw-r--r-- 1 anon anon 23356543 Sep 19 01:28 txtdata.tzst
xz-9:txtdata
real    1m32.539s
user    1m32.019s
sys     0m0.483s
-rw-r--r-- 1 anon anon 23125096 Sep 19 01:26 txtdata.txz

Ответить | Правка | Наверх | Cообщить модератору

22. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"  +/
Сообщение от Аноним (8), 19-Сен-20, 01:50 
Распаковка в… Ну у меня получилось в 5 раз быстрее, но вообще там очень медленно и тут просто мелких файлов много наверно, 0.3с сложно с 1.5с сравнивать.
Ответить | Правка | Наверх | Cообщить модератору

33. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"  –3 +/
Сообщение от Аноним (33), 19-Сен-20, 05:39 
zstd никогда не был быстрее lzma2, а уж тем более непрерывного архива rar5.

zstd быстр на распаковке ценой меньшей степени сжатия за короткое время.

не нужно при помощи него сжимать данные на хранение! для этих целей есть rar5.

Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

41. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"  +2 +/
Сообщение от Аноним (5), 19-Сен-20, 07:47 
Вы видимо анонимный эксперт, вам скорость или время?
Ответить | Правка | Наверх | Cообщить модератору

133. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"  –1 +/
Сообщение от Аноним (133), 21-Сен-20, 09:00 
вы видимо админ локалхоста, попробуй сохрани в облаке пожатый архив размером в 100ТБ, посчитай сколько бабла тебе это встанет, и поймеш зачем нужен РАР5.
Ответить | Правка | Наверх | Cообщить модератору

134. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"  –1 +/
Сообщение от Аноним (133), 21-Сен-20, 09:04 
а оно в мультипоточность умеет, или такое же как и gzip, однопоточное гв-но? даже pigz легко обходит тот-же gzip ровно в Х-раз, где Х это количество доступных ядер.
Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

135. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"  +/
Сообщение от Аноним (135), 21-Сен-20, 12:50 
> а оно в мультипоточность умеет, или такое же как и gzip, однопоточное
> гв-но? даже pigz легко обходит тот-же gzip ровно в Х-раз, где Х это количество доступных ядер.
>> Сжатие и распаковка блока ФС в ядре
>> мультипоточность
>> pigz

А гонору-то, гонору сколько было *рукалицо*

Ответить | Правка | Наверх | Cообщить модератору

28. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"  +/
Сообщение от Аноним (5), 19-Сен-20, 04:09 
pigz и lbzip2/pbzip2 должно быть тоже быстро
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

43. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"  +/
Сообщение от Аноним (93), 19-Сен-20, 08:48 
1. У zstd упаковка адово тормозная на высоком сжатии.
2. Степень сжатия сильно зависит от datasetа и от способа применения. У меня в black-box сценарии lzma2 пожал лучше, чем zstd, оба на максималках, а лучше обоих пожал ... brotli.
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

76. "Red Hat развивает новую ФС NVFS, эффективную для NVM-памяти"  +/
Сообщение от Аноним (5), 19-Сен-20, 12:41 
Как насчет потребление ресурсов ЦПУ в многопотоке на SSD/NVMe I/O?
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру