Jari Ruusu wrote:
> Matthias Schniedermeyer wrote:
>> 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
>
> Did you test it through a file system or direct to loop device?
I discovered the slow performance while "initializing" the loop with
dd if=/dev/zero of=/dev/loop<x>
(Currently i'm not sure if i also used a bs=<whatever>, maybe not)
So direct to loop it is.
I haven't tested putting a filesystem on the loop, at that point i just
wanted a completely zeroed loop (so i had a seemingly "random"
backing-store).
So it appears that only a note about "direct" use of loop may be
suboptimal for offseted loops. E.g. when you "zero" over the loop (which
is definetly IO or CPU-bould) instead of "randomizing" over the loop or
directly to the backing store.
(Random-performance wasn't great AFAIR, so i settled with zeroing over
the loop. Which i think is "good enough", given that a) it's v3 (65th
key alone should prevent "detecting" zero blocks when next to no
knowledge exists about the plain-text) and b) i use a different key for
each loop (see below))
> Direct to loop device test has disadvantage of possibly un-optimal default
> soft block size. If loop device size is not multiple of page size, then
> smaller than page size soft block size default is set at losetup time. This
> may affect performance when loop device is read/written directly. File
> system mount of course sets better soft block size and bangs the device
> using more optimally sized reguests. Using offset=512 shrinks loop device
> size. What does "blockdev --getsize /dev/loop4" command output now (using
> 4096 byte offset)?
I think the total capacity is quite irrelevant for this case, it's the
expected HDD size minus 8 Blocks?
blockdev --getsize /dev/loop2
976773160
vs.
blockdev --getsize /dev/sdb
976773168
(Loop-No. changed because 1) i just used 4 and b) i automount just about
everything.(*))
So guess we can settle the case and i will just have to live with 143,50
KB (or .00000127 percent of total capacity) of "lost" space due to
assuming a poorly performing "direct to loop" would also lead to a
poorly performing "filesystem over loop".
*:
I put the "name" of the HDD at 0x1b8 of the MBR, which is documented as
"could be used for a 4 byte 'ID'" (Another reason why i wanted to spare
the MBR, so i could place a marker somewhere in it)
Naming schema i use is xm and 2 digits.
Placing the marker works like this:
echo "xm01" | dd bs=1 count=4 seek=440 conv=notrunc of=/dev/sd<x>
Then i wrote a little shell script that extract the marked and outputs a
udev-complying string:
- snip -
if [ "$1" != "" ]; then
label=`dd if="$1" bs=1 count=4 skip=440 status=noxfer 2>/dev/null`
echo "$label" | grep ^xm &>/dev/null && echo "ID_XM=$label"
fi
- snip -
With a matching udev-rule:
- snip -
# Check for xm-disc
KERNEL=="sd*[!0-9]", \
IMPORT{program}="/usr/local/bin/my/xm_id.sh $tempnode"
ENV{ID_XM}=="xm[0-9][0-9]", \
SYMLINK+="disk/by-xm/$ENV{ID_XM}"
- snip -
Which means a symlink like "xm01" is registered for each HDD where a
marker is found into the directory "/dev/disk/by-xm/", which points to
the /dev/sd<x>-device it gets when it is connected. (In my case mostly
USB2.0, but i will move to (e)SATA in the future. Now that hotplugging
SATA actually works and (e)SATA has way better performance)
And, at last, with an also matching automount-entry (1 line!):
xm01 -fstype=xfs,noatime,encryption=aes128,offset=4096,gpgkey=xm01.gpg
:/dev/disk/by-xm/xm01
I have all the "magic" in place it needs to automount the encrypted HDDs
despite them being encrypted. Before encryption i i just used LABELd or
UUIDed filesystems, but encryption prevents that, especially when you
use different keys for different loops.
(My current statistics are: 41 HDDs with a 10,5 TiB total capacity and 9
TiB used. Currently being converted from unencrypted to encrypted, which
will probably take as long as sometime next month, averaging somewhere
over a day per HDD.)
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/
