Будет использование сжатой файловой системы по зашифрованному тому, улучшают производительность?

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

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

6
23.03.2013, 12:00
1 ответ

Я сделал маленький сравнительный тест. Это только тестирует записи все же.

Данные тестирования являются исходным деревом ядра Linux (linux-3.8), уже распакованный в память (/dev/shm/tmpfs), таким образом, должно быть как можно меньше влияния от источника данных. Я использовал сжимаемые данные для этого теста, так как сжатие с несжимаемыми файлами не имеет смысла независимо от шифрования.

Используя btrfs файловую систему на объеме LVM на 4 ГиБ, на LUKS [AES, xts-плоскость, sha256], на RAID-5 более чем 3 диска с 64 КБ chunksize. ЦП является Intel E8400 2x3Ghz без AES-NI. Ядро является 3.8.2 x86_64.

Сценарий:

#!/bin/bash

PARTITION="/dev/lvm/btrfs"
MOUNTPOINT="/mnt/btrfs"

umount "$MOUNTPOINT" >& /dev/null

for method in no lzo zlib
do
    for iter in {1..3}
    do
        echo Prepare compress="$method", iter "$iter"
        mkfs.btrfs "$PARTITION" >& /dev/null
        mount -o compress="$method",compress-force="$method" "$PARTITION" "$MOUNTPOINT"
        sync
        time (cp -a /dev/shm/linux-3.8 "$MOUNTPOINT"/linux-3.8 ; umount "$MOUNTPOINT")
        echo Done compress="$method", iter "$iter"
    done
done

Таким образом в каждом повторении, это делает новую файловую систему и измеряет время, которое требуется для копирования источника ядра Linux из памяти и umount. Таким образом, это - чистый тест записи, нулевые чтения.

Результаты:

Prepare compress=no, iter 1

real 0m12.790s
user 0m0.127s
sys 0m2.033s
Done compress=no, iter 1
Prepare compress=no, iter 2

real 0m15.314s
user 0m0.132s
sys 0m2.027s
Done compress=no, iter 2
Prepare compress=no, iter 3

real 0m14.764s
user 0m0.130s
sys 0m2.039s
Done compress=no, iter 3
Prepare compress=lzo, iter 1

real 0m11.611s
user 0m0.146s
sys 0m1.890s
Done compress=lzo, iter 1
Prepare compress=lzo, iter 2

real 0m11.764s
user 0m0.127s
sys 0m1.928s
Done compress=lzo, iter 2
Prepare compress=lzo, iter 3

real 0m12.065s
user 0m0.132s
sys 0m1.897s
Done compress=lzo, iter 3
Prepare compress=zlib, iter 1

real 0m16.492s
user 0m0.116s
sys 0m1.886s
Done compress=zlib, iter 1
Prepare compress=zlib, iter 2

real 0m16.937s
user 0m0.144s
sys 0m1.871s
Done compress=zlib, iter 2
Prepare compress=zlib, iter 3

real 0m15.954s
user 0m0.124s
sys 0m1.889s
Done compress=zlib, iter 3

С zlib это намного медленнее, с lzo немного быстрее, и в целом, не стоящий беспокойства (разница является слишком небольшой для моего вкуса, полагая, что я использовал легкие к сжатию данные для этого теста).

Я сделал бы тест чтения также, но это более сложно, поскольку необходимо иметь дело с кэшированием.

8
27.01.2020, 20:26
  • 1
    Большой тест. Полагание, что во многих случаях данные сжимаемы (как /usr), это было бы полезно. Я предполагаю, что тест чтения мог быть сделан тот же путь путем простой очистки кэша. –  Petr Pudlák 23.03.2013, 21:30
  • 2
    я протестировал чтение с помощью подобного сценария, стараясь избегать кэша, и кажется, что никакое сжатие не лучше, чем lzo. Вероятно, время, использованное сжатием, выше, чем, что оно экономит на стороне шифрования. –  Petr Pudlák 24.03.2013, 23:34
  • 3
    Для скоростей чтения я получаю лучшие результаты для zlib (4246), сопровождаемые lzo (4648), сопровождаемые никаким сжатием (5859). Мой тест чтения был time (xargs cat < /dev/shm/files | md5sum) (файлы, являющиеся всеми файлами в дереве ядра linux-3.8), после sync ; echo 3 > /proc/sys/vm/drop_caches и недавно смонтированная фс, как место размещения записи umounts. Таким образом... zlib занимает больше времени для записи, но является самым быстрым для чтения. Если Ваши файлы все легко сжать. Я все еще не обеспокоюсь им лично, но ymmv. –  frostschutz 25.03.2013, 00:29

Теги

Похожие вопросы