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.
