Re: RAID1 + LoopAES concurrent access

On Dec 15, 2007 4:04 PM, markus reichelt <[email protected]> wrote:

That being said, your box behaves strangely. I guess it cannot be
> attributed to loop-AES or dm-crypt at all.


Well, when I tested dm-crypt on my own desktop and found this concurrent
access issue, I read a lot about it and it seemed related to a bad handling
in dm-crypt using blocking I/O to ensure that encrypted data really was
commited to disks at all times. So finally, I wasn't that surprised by the
dm-crypt behaviour.

I really thought LoopAES wouldn't be affected by such behaviour because of a
really different design so I wanted to test it in a real world situation.


> I experienced a similar sort of timeout whilst using the main HD and
> an optical drive on the same IDE controller channel (master+slave
> both present). Unfortunately I cannot tell you which hardware I
> exactly used, it was a PATA only system. And the strange delays went
> away when I switched to one drive per IDE channel.


The only thing I can think of is the way disks are connected. The
SiliconImage SI3512 chip is on a PCI card having 2 SATA connectors. As the
RAID configuration is done at kernel level, a single write on /dev/md0 is
sent twice over the wire to reach both disks (RAID1 with 2 disks).

33MHz PCI is limited to 133MB/s bandwidth and according to the hdparm values
I gave in the first message, full disk speed x 2 would saturate the PCI bus
for unencrypted operation and would nearly saturate it for LoopAES encrypted
operation.

Maybe this is just the problem... The motherboard (Asus K8V-X) internal SATA
controler does not recognise the Hitachi 500GB disks at boot, hence the use
of a more modern chip on a separate PCI card. Also, this motherboard doesn't
feature PCI-E bus/slots.

My own Desktop is full PCI-E with 6 SATA connectors so I'll find some time
to test the setup as-is with my motherboard and see, this time, if I still
get the concurrent access troubles.


> That being said for the record, your problem seems to be of a
> trickier sort. Did you test all this with an unencrypted system?


Unfortunately no.. but if my previous guess is right, I should too face the
concurrent access problem.


> I've been using fully encrypted systems for quite some time now for
> quite some setups and your report really is news to me.


News to me too because I really did not find any report of such behaviour in
the ML archive.

-- 
Unix _IS_ user friendly, it's just selective about who its friends are.