[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: README losetup/mount-Parameter "offset" needs another note
Jari Ruusu wrote:
> Matthias Schniedermeyer wrote:
>> So i set the offset to 512 with "/dev/sd<x>" as the backing-store. But
>> Performace fell to a crawl (relativly speaking) realative to a
>> non-offseted loop.
>>
>> So i increased the offset by 512 for a few times in the hope that the
>> phaenomenom is "curable". And with an offset of 4096 performance was the
>> same as without an offset.
>>
>> As i have a IA32-System it appears to me that the offset has to be
>> page-aligned, in case performance matters. So i suggest to put a note
>> about that in the README.
>
> What kernel version are you using?
2.6.19, vanilla, self-compiled (But later this day it will be 2.6.20)
> What loop implementation are you using?
loop-aes 3.1e
(I'm a loop-aes user for 3-4 years)
> Mainline loop driver uses page cache for both file backed and device backed
> setups. Loop-AES version of loop driver uses page cache only for file backed
> setups. Your description sounds like you are using mainline loop.
I case numbers matter.
CORE2 Duo E6700, 2GB DDR2-800 RAM
(Or about the fastest "not extreme" system currently available)
"RAW" AES128-v3 throughput this system can reach is about 100MB/s (using
a single thread of aespipe)
- snip -
time (dd if=/dev/zero bs=20480 count=52428 | aespipe -e aes128 -p3 3< <(
gpg < key.gpg ) > /dev/null)
52428+0 records in
52428+0 records out
1073725440 bytes (1.1 GB) copied, 10.9219 seconds, 98.3 MB/s
real 0m10.924s
user 0m7.977s
sys 0m0.657s
- snip -
(Currently my system is working, numbers are a little bit better with 0
load)
HDD is a 500GB Seagate/PATA, connected to a onboard jmicron
PATA-Controller(apears to be a PCIe device) and driven by the matching
libata driver. The HDD delivers a linear throughput of about 70-73MB/s,
which doesn't decrease much when i put a aes128-v3-loop over it, and
which uses about 1/2 of the available CPU-ressources
gpg < key.gpg | losetup -e aes128 -p 0 /dev/loop4 /dev/sdb
The same loop, with the "not good" offsets of 512-3584, decreases the
throughput to a craw of 5-20MB/s (don't have exact numbers anymore and
currently my system is working, so i can't retest)
With an offset of 4096 everything is good(tm) again.
gpg < key.gpg | losetup -e aes128 -p 0 -o 4096 /dev/loop4 /dev/sdb
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
-
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/