You are not logged in.
Pages: 1
I switched from LUKS to an encfs-encrypted setup for one partiton to be able to access it from other (non-*nix) operating systems.
Layering is now: RAID1-Volume --> ntfs-3g --> encfs.
The problem is the write speed I'm currently having while copying the contents over: ~6.63MB/s. The RAID can do ~65MB/s, and I see no CPU load (Core i7-920).
I've read many articles about performance concerns with user-mode filesystems and the additional context-switches (or better mode-switches) they require, but come on - 6MB/s??
Any ideas or hints are welcome
Offline
Well, as I have access to the system now I think I could add some more details:
encfs:
- EncFS 1.7.4
- cipher: AES-256
- blocksize: 1024
- unique IV
- chained name IVs
ntfs-3g:
- ntfs-3g 2011.4.12-1
- blocksize: 4096
- mount options: uid=lynix,gid=users,fmask=113,dmask=002
system:
- kernel26-ck-core2 2.6.39.3-1
- bfq I/O scheduler registered for the RAID volumes
Please ask if there's something missing
Offline
Perhaps your drive is not master........................
Prediction...This year will be a very odd year!
Hard work does not kill people but why risk it: Charlie Mccarthy
A man is not complete until he is married..then..he is finished.
When ALL is lost, what can be found? Even bytes get lonely for a little bit! X-ray confirms Iam spineless!
Offline
What do you mean with "master"?
They're all SATA drives...
Offline
My system has four SataII ports. They are arranged in pairs, master and slave,,ID ch2M ..ch2S..ch3M..ch3S.
In raid arrays, I must use master(s).
This is what I mean by master.
My system is x86_64 with GA-945GCM-S2C mobo.
If I don't use master devices, my raid speed is cut in half(if only one of three devices is a slave).
Your system may not have master/slave arrangement so disregard.................
Prediction...This year will be a very odd year!
Hard work does not kill people but why risk it: Charlie Mccarthy
A man is not complete until he is married..then..he is finished.
When ALL is lost, what can be found? Even bytes get lonely for a little bit! X-ray confirms Iam spineless!
Offline
Thanks for the explanation, I didn't know there can be designated ports.
I have write speeds of ~65 MB/s on the other volumes of the RAID array, so I assume this is not the bottleneck.
Offline
My system has three raid devices in a bootable archlinux 64bit system using SataII to CF cards with adapters. Raid0.....
Each drive has ~60-65MB/s in hdparm and the raid device reports 186MB/s in hdparm.
I needed pcie adapter for Sata to obtain the third master connection.
I plan on a fourth install today with a Kingston 600x device (16GB for eachdevice). I have one pcie port open, an independent port.
Last edited by lilsirecho (2011-07-15 15:46:52)
Prediction...This year will be a very odd year!
Hard work does not kill people but why risk it: Charlie Mccarthy
A man is not complete until he is married..then..he is finished.
When ALL is lost, what can be found? Even bytes get lonely for a little bit! X-ray confirms Iam spineless!
Offline
You're layering a FUSE filesystem on top of another FUSE filesystem and you're still expecting to have performance?
As for master/slave: that's only an issue if you still use IDE emulation, and probably only with certain chipsets. Modern SATA controllers in AHCI or RAID mode don't suffer if you populate SATA0+1 instead of SATA0+2.
Offline
I'm not expecting a level of performance that is comparable with LUKS or no encryption at all
But at least I would expect a visible cpu load while having so bad transfer speed. I understand that layering FUSE filesystems is not very clever, but if there are so many context switches why can't I se any load?
Offline
By the way, isn't truecrypt FUSE-based too? I just killed the volume and setup a new one with truecrypt.
51.77 MB/s write speed now...
Offline
You'll probably get high load because things go in D-state. You won't notice much CPU load simply because the kernel will be much slower processing your data:
Plain filesystem:
user app -> kernel fs/block
FUSE filesystem:
user app -> kernel -> user through FUSE -> kernel block
FUSE filesystem on top of FUSE filesystem:
user app -> kernel -> user through FUSE -> kernel -> back to FUSE -> kernel block
Doing that wastes a lot of clockcycles, and wasted clockcycles don't count up for CPU usage. Try creating a program that sleeps a lot: same slowness, but no CPU load.
Offline
Okay I understand that all these memcpy() from user to kernel-space don't count als real load.
But as I already asked: what is so different with truecrypt? There should be the same layering and buffer copying...
Offline
In the beginnung you had: RAID1-Volume --> ntfs-3g --> encfs
Now you have: RAID1-Volume --> truecrypt-filesystem.
That's one damn slow punk less in the middle. I also had issues with NTFS partitions. They gave me a maximum read of 20 mb/s and a maximum write of 10 mb/s. They also blocked my cpu completely, I couldn't even move windows in the process. While I know that this is a problem that might need fixing (ntfs-3g is not bad at all, usually), I switched to EXT4 for all my old data partitions and now I have up to 80 mb/s throughput (non-raid) and no extra process eating my cpu power away.
Offline
I still have ntfs-3g as truecrypt doesn't have its own filesystem:
RAID1 --> truecrypt (/dev/mapper/truecrypt1) --> ntfs-3g
Same amount of indirections, but truecrypt instead of encfs and ntfs-3g last instead of second.
As shown by mount:
truecrypt on /tmp/.truecrypt_aux_mnt1 type fuse.truecrypt (rw,nosuid,nodev,allow_other)
/dev/mapper/truecrypt1 on /mnt/storage type fuseblk (rw,nosuid,nodev,noatime,allow_other,blksize=4096,default_permissions)
So I suspect it might be somehow the order of the layering? I also do not have the speed issues with NTFS-partitions you describe: 75 MB/s read with ntfs-3g under ~14% cpu load.
Last edited by lynix (2011-07-19 20:33:48)
Offline
Pages: 1