Мне обычно не нужен материал медиа/кодеков для моих полей Centos, но я определенно делаю на своих рабочих столах Fedora. Для последнего случая я получаю их от RPMFusion, который просто, оказывается, имеет репозитории для RHEL5-совместимых выпусков, таким образом, я предложил бы выглядеть там первым.
Я спросил Richard Elling, экс-солнце, ZFS проектируют этот вопрос. Он сказал мне, что L2ARC является несжатым, точно так же, как ARC является несжатым.
Извините, я не могу предоставить документацию или спецификации. Мое единственное доказательство - то, что один из парней, которые помогли разработать ZFS, сказал мне лично, когда я встретил его на прошлой неделе.:)
Да. ZFS будет кэшироваться, часто получал доступ к данным в любой форме. Производительность со схемой сжатия по умолчанию хороша и стоит только небольшого процессорного времени. Сжатие сделано на лету. Можно расширить это еще больше путем добавления устройства SSD L2ARC кэша.
Кэшированные данные в ARC или L2ARC являются всегда несжатыми. Период. Иначе каждое чтение от ARC или L2ARC имело бы соответствующий ЦП наверху, который с некоторыми алгоритмами мог быть значительным (я смотрю на Вас bzip2). Принятие compression=yes в Вашей файловой системе (системах), данных по дискам пула и ZIL (если применимо), будет всегда сжиматься.
Вы корректны, храня данные, которые сжимаются хорошо и система с большим количеством ЦП, но ограниченный IO мог бы формовать лучше с включенным сжатием. Это не уникальная характеристика ZFS, Вы найдете много ссылок на это относительно включения сжатия на NTFS или других файловых системах.
Сегодня L2ARC может быть сжат с помощью LZ4, но ARC все еще не сжат. Дополнительная информация доступна на веб-сайте OpenZFS -> http://open-zfs.org/wiki/Features#l2arc_compression
Это изменилось в последних версиях zfs (по крайней мере, в Linux). Мы только что сравнили яблоки с яблоками с двумя наборами данных 32k, один со сжатием lz4, другой без него. Память, используемая arc, была удвоена в случае несжатия.
Похоже, что на самом деле обычно более эффективно распаковать данные, которые действительно необходимы, в краткосрочный кеш, поскольку кеш arc часто считывает данные, которые никогда не запрашиваются . Похоже, выбор был сделан для сжатия в памяти ..
Я также вижу несколько параметров в файле / proc / spl / kstat / zfs / arcstats, которые подтверждают это:
c 4 135156049920
c_min 4 8447253120
c_max 4 135156049920
size 4 3288083480
compressed_size 4 3070738432
uncompressed_size 4 9339208192
Этот коммит выглядит актуальным https://www.illumos.org/issues/6950