The OpenNET Project / Index page

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



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

Оглавление

Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..., opennews (??), 27-Фев-12, (0) [смотреть все]

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


4. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."  –6 +/
Сообщение от Васька. (?), 27-Фев-12, 16:17 
Непонятно, зачем сжатие файловой системе? Хранить в два, ну почти три раза больше данных :-( данные данным рознь, не получится из этого ничего хорошего.
Ответить | Правка | Наверх | Cообщить модератору

5. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."  +9 +/
Сообщение от Блуд (??), 27-Фев-12, 16:24 
Всё очень просто. Храня сжатые данные, требуется меньше времени на их считывания. А учитывая, что жёсткий диск является медленным устройством, то сжатие - большой плюс!
Ответить | Правка | Наверх | Cообщить модератору

11. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."  –6 +/
Сообщение от Анодуб (?), 27-Фев-12, 16:33 
Больше кэшей! Больших и разных.
Ответить | Правка | Наверх | Cообщить модератору

17. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."  –1 +/
Сообщение от Аноним (-), 27-Фев-12, 16:48 
При рандомном доступе к многотерабайтному массиву, для более-менее эффективной работы размер кэша должен быть сопоставим с размером массива. Во-первых, дорого, во-вторых, неустойчиво к сбоям. Порочность этого пути хорошо видна на примере ZFS, которая выдает приемлемую производительность только в "режиме стримера" (т.е. исключительно при линейном доступе).
Ответить | Правка | Наверх | Cообщить модератору

41. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."  +/
Сообщение от Аноним (-), 27-Фев-12, 19:21 
Как рандомно обратиться к запакованным данным? Сперва секцию с данными целиком прочитать, потом распаковать, потом только обратиться к нужному месту. Рандомное обращение - плохой пример.
Ответить | Правка | Наверх | Cообщить модератору

47. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."  +/
Сообщение от Аноним (-), 27-Фев-12, 23:31 
Очень сильно зависит от размера секции.
Ответить | Правка | Наверх | Cообщить модератору

58. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."  +/
Сообщение от VoDA (ok), 28-Фев-12, 01:08 
> Как рандомно обратиться к запакованным данным? Сперва секцию с данными целиком прочитать,
> потом распаковать, потом только обратиться к нужному месту. Рандомное обращение -
> плохой пример.

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

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

63. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."  +/
Сообщение от Аноним (-), 28-Фев-12, 01:59 
> Как рандомно обратиться к запакованным данным?

Так же как и к остальным - никто не жмет огромные блоки. Сжатие идет небольшими кусками, чего впрочем вполне хватает для профита на рыхлых данных. Да, 7zip сожмет покруче. И даже очень. Вот только скорость... ;)

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

62. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."  +/
Сообщение от Аноним (-), 28-Фев-12, 01:58 
> Больше кэшей! Больших и разных.

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

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

71. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."  +/
Сообщение от Аноним (-), 28-Фев-12, 08:04 
А еще это решение является концептуальным в своем роде. Подумайте сами - с ростом производительности системы можно встраивать в btrfs более "тяжелые" алгоритмы при этом лишь надо соблюсти соотношение скорость сжатия/распаковки со скоростью чтения/записи на носитель.
Ответить | Правка | Наверх | Cообщить модератору

72. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."  +/
Сообщение от Аноним (-), 28-Фев-12, 08:23 
> с ростом производительности системы можно встраивать в btrfs более "тяжелые" алгоритмы

Ну вот zlib зачастую не поспевает за накопителем, т.к. 2-ступенчатый (LZ -> huffman). А вот эти алгоритмы - быстрые, распаковка такой штуки вообще напоминает немного продвинутый вариант memcpy. Поэтому обычно они (LZO, Snappy, LZ4) - шустрее. Накопители, btw, тоже на месте не стоят: появились ssd которым 6Гбит sata - мало, так что они в pci-e втыкаются. Стоят конечно конских денег, но ведь и скорость - под стать...

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

88. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."  +/
Сообщение от Аноним (-), 28-Фев-12, 17:17 
А как насчет LZMA ? ИМХО, кажется он совершенно пригоден для сжатия на уровне фс (ядра-то мы давно уже сжимаем им).
Ответить | Правка | Наверх | Cообщить модератору

90. "Представлены патчи для Btrfs с поддержкой алгоритма..."  +/
Сообщение от arisu (ok), 28-Фев-12, 17:23 
> А как насчет LZMA ?

с дуба рухнул, штоле? скорость сжатия ужасающа, скорость разжатия ужасающа.

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

117. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."  +/
Сообщение от Аноним (-), 05-Мрт-12, 17:36 
> А как насчет LZMA ?

Хоть его и портировали на чистый си в конце концов и даже в виде годном для пихания в ядро...
1) По скорости сжатия он еще хуже zlib, потому что делался с оглядкой на максимальное сжатие.
2) При мелком размере блока разогнаться с крутым сжатием особо негде и не на чем. А жать большой блок - долго и RAM много надо...
3) По скорости распаковки он как и все LZ-based довольно ничего, но... но довольно хардкорная несимметрия скоростей сжатия и распаковки ограничивает его применение в штуках типа squashfs или сжатия ядра, где распаковка - есть, а упаковки - нет. Просто потому что упаковка может быть длительной и потребовать много ресурсов, что слегонца неприемлимо для сжатия работающего на лету.

Технически кстати LZMA всего лишь развитие все тех же идей: 2-ступенчатый алгоритм, LZ-подобное сжатие которому дозволено юзать более крупный словарь чем zlib с его куцыми 32кб + марковские цепочки как вторая стадия. Жмет хорошо но медленно. Распаковывается более-менее резво (как и любой иной LZ-based). Рекордные скорости не покажет из-за двустадийности (распаковка голого LZ без второй стадии может быть крайне быстрой в силу простоты этой операции).

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

6. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."  +/
Сообщение от igoree (?), 27-Фев-12, 16:25 
библиотека мошкова кашерно разместится)
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

7. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."  +/
Сообщение от Анонут (?), 27-Фев-12, 16:28 
Да,да вспоминаются времена dblspace под досом. Когда можно было из 40Мб сделать как-бэ 120Мб. Реально влезало на 1-2Мб больше. При малейшем сбое на винте - данные терялись чуть менее чем все.

Может сейчас оно уже не так ужасно. Прогресс всетаки.

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

15. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."  +4 +/
Сообщение от inferrna (?), 27-Фев-12, 16:43 
Ну, во-первых, там и в 95-98 винде сжимался вроде-как весь диск и при внешнем монтировании это дело выглядело как 1 большой файл и горстка маленьких. Тут, всё-таки, сжимаются отдельные файлы. Во-вторых, по-умолчанию там "compress highly compressible files, but back off and blacklist incompressible content".
Ответить | Правка | Наверх | Cообщить модератору

73. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."  +/
Сообщение от Аноним (-), 28-Фев-12, 08:31 
> Да,да вспоминаются времена dblspace под досом. Когда можно было из 40Мб сделать
> как-бэ 120Мб. Реально влезало на 1-2Мб больше.

Реально - зависело от того что там хранить. Понятный пень что уже сжатые жыпеги и гифы еще раз не сожмутся. А вот рыхлые текстовики, бинарники системы и прочие doom2.wad - на раз жмутся в 2-3 раза, обеспечивая вполне себе профит. Правда там алгоритм сжатия был не чемпион по скорости и потому о выигрыше в скорости речь не шла. Но с ростом мощщи проца, появлением кучи ядер и развитием скоростных алгоритмов типа того же LZ4 - появился повод вспомнить давно забытое старое еще раз. На новом технологическом уровне.

> При малейшем сбое на винте - данные терялись чуть менее чем все.

Все - не терялись, но вот утилиты починки диска реагировали на такие диски довольно странно. Вообще оно было довольно криво сделано, два набора чувствительных структур (FAT и CVFAT), и журнала опять же нет, а во времена доса - еще и защиты памяти драйвера. Так что небольшой факап программы мог порушить память драйверу сжатия и устроить довольно массовый дестрой данных на томе.

> Может сейчас оно уже не так ужасно. Прогресс всетаки.

Ну так времена ОС без защиты памяти, фс без журналирования и что там еще - закончились.

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

9. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."  +/
Сообщение от x0r (??), 27-Фев-12, 16:30 
ну если не сжалось - можно и записать как есть.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

51. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."  +/
Сообщение от Аноним (-), 28-Фев-12, 00:10 
ты видел сколько бдрипы стартрека занимают? в ноут такой диск пока не впихнёшь.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

77. "Представлены патчи для Btrfs с поддержкой алгоритма..."  –1 +/
Сообщение от arisu (ok), 28-Фев-12, 12:01 
> ты видел сколько бдрипы стартрека занимают?

во времена TOS никакого «б» не было. а остальным место в помойке.

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

61. "Представлены патчи для Btrfs с поддержкой алгоритма сжатия L..."  +/
Сообщение от Аноним (-), 28-Фев-12, 01:57 
> Непонятно, зачем сжатие файловой системе?

Скорость записи и особенно чтения с столь скоростными алгоритмами может быть _быстрее_ чем скорость чтения-записи несжатых файлов. Просто потому что читать-писать меньше и если все упиралось в накопитель, ему внезапно полегчает в пару раз -> PROFIT.

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

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

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




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

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