RAID1 + LoopAES concurrent access

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

I've setup a RAID1 + LoopAES system on a Gentoo box using my own kernel (2.6.23) patched with loopaes only.

The box is not high end hardware but enough to sustain the load (AMD Sempron 3100+, 1GB RAM).

The disks are Hitachi 500GB SATA HDT725050VLA380 connected to a PCI SATA controler using a SiliconImage SI3512 chip.

Some months ago, I tested LUKS with encrypted root on my own desktop (Ubuntu Feisty at that time and a plain disk, no RAID) and the only real drawback I had was the concurrent access which was a performance killer... A simple dd if=/dev/sda of=/dev/null in background made quite "impossible" to load firefox and browse the net at the same time, or using any other tool. All I/O seemed block until I stopped DD.

Then, I read a lot of articles and came up to try LoopAES which was supposed to perform better, performance and security wise, and it does at least on the CPU usage side.

So, I ssh to the Gentoo box, launch screen to have multiple "consoles" and start to fill the disk with my backup data using :

ssh root@backupserver "cd / ; tar -c -f - list_of_backupable_dirs" | tar -x -f -

Everything runs smooth and seems to be quite fast. Then I create a new login shell with screen (Ctrl+a c) and.. wow... it's SLOW... then I launch midnight commander and start browsing the filesystem.. Incredible how slow this can be.

Reading thoroughly loopaes.README, I switch the IO Scheduler to deadline and tried again all that stuff. Deadline improved a bit the responsiveness but not that much. Yes, that's better than Anticipatory but still very slow compared to normal operations.

The purpose of the Gentoo box is to become the future mail server as well as file server for our small company. Even with high performance SMTP and IMAP servers such as Postfix and Cyrus/Dovecot, it'll imply quite a lot of concurrent accesses.

So the question : Is that normal behaviour or did I missed something ?

I've read a lot of articles from the archive and I don't remember reading people complaining about concurrent access troubles.

Here is some (maybe?) useful info :

root@server # losetup /dev/loop0
/dev/loop0: [0001]:299 (/dev/md0) encryption=AES128 multi-key-v3

root@server # cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb1[1] sda1[0]
      488383936 blocks [2/2] [UU]
      bitmap: 0/233 pages [0KB], 1024KB chunk

root@server # hdparm -tT /dev/md0 /dev/loop0 /dev/sda /dev/sdb

/dev/md0:
 Timing cached reads:   1002 MB in  2.00 seconds = 500.90 MB/sec
 Timing buffered disk reads:  230 MB in  3.01 seconds =  76.46 MB/sec

/dev/loop0:
 Timing cached reads:   1002 MB in  2.00 seconds = 500.74 MB/sec
 Timing buffered disk reads:  150 MB in  3.00 seconds =  49.92 MB/sec

/dev/sda:
 Timing cached reads:   1002 MB in  2.00 seconds = 500.74 MB/sec
 Timing buffered disk reads:  230 MB in  3.02 seconds =  76.07 MB/sec

/dev/sdb:
 Timing cached reads:   1002 MB in  2.00 seconds = 500.88 MB/sec
 Timing buffered disk reads:  230 MB in  3.02 seconds =  76.04 MB/sec

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

[Index of Archives]     [Kernel]     [Linux Crypto]     [Gnu Crypto]     [Gnu Classpath]     [Netfilter]     [Bugtraq]
  Powered by Linux