Write load on DM-Crypt LUKS partition (reiserfs and ext3) jams system
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Linux |
Fix Released
|
Medium
|
|||
linux (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
linux-source-2.6.20 (Ubuntu) |
Won't Fix
|
Medium
|
Unassigned |
Bug Description
Binary package hint: linux-image-
I'm running Kubuntu Feisty, installed via the i386-desktop ISO-image snapshot of 2007-01-11, with the latest apt-get upgrades as of today.
The recently purchased computer has an AMD "Sempron 3400+" CPU (AM2-socket) installed on a mainboard with Nvidia n-force 6100-430 chipset.
The harddrive is a new 400GB SATA disk connected to the onboard SATA-terminal (kernel module: sata_nv).
In addition to three smaller and unencrypted partitions (system, swap and home; still unencrypted because it's a testing setup), I created a 322-GB partition for encrypted data storage.
This partition is LUKS-formatted via cryptsetup/DM-Crypt and has a Reiserfs file system.
The problem is the following:
Whenever I copy a slightly bigger file (e.g. 500MB) /to/ the dm-crypt-partition, the system is almost blocked for the duration of the copying process.
This means that not only the system responsiveness gets rather low, but that, approx. once every two seconds, the system is completely "stalled" for a second.
Even the mouse pointer and Amarok sound playback periodically stop completely.
It doesn't matter if the source is one of the unencrypted partitions on the same harddisk, a CD-ROM or even an NFS-mount from a (compared to local copying) relatively slow remote server.
This is particularly undesireable, e.g. if a database system for sensitive customer data is using the partition, or if the recording of video live-streams from surveillance cameras blocks the rest of the system.
And especially since I thought the new standard CFQ-IO-scheduler would prevent those problems.
By observing the write performance of my system, I could determine an anomaly which also seems to be connected with the above described lock-ups:
Data transfer rates obtained via " time cp 'sourcelocation
Write performance:
copy:
from one unencrypted filesystem to annother unencrypted filesystem on the same harddrive: 38MByte/sec
from unencrypted filesystem to encrypted filesystem on the same harddrive: 16MByte/sec
from 100-MBit/sec LAN NFS-mount to unencrypted filesystem on local machine: 11.2MByte/sec (maximum for 100MBit-LAN)
from 100-MBit/sec LAN NFS-mount to encrypted filesystem on local machine: 6.5MByte/sec
(even though 16MB/sec were possible from the local source before, and the LAN is also capable of 11.2MB/sec [!]
This is the anomaly I meant before.)
Read performance from encrypted partition (" time cp 1-GB-testfile.dat /dev/null " or even " time cp 1-GB-testfile.dat /tmp " (no RAM tmpfs))
is perfect with 28 respectively 26 MByte/sec; no system lock-ups.
To further investigate the issue, I have compiled the vanilla 2.6.19.2 kernel from kernel.org. Result: same behaviour.
If this is an upstream kernel bug, I'm sorry, but I am not that proficient with programming and the kernel and I couldn't determine how much there are userspace programs or even the default configuration details of the Ubuntu distribution are involved.
I'm attaching the output of "dmesg" and "lspci" for my system (running linux-image-
Changed in linux-source-2.6.20: | |
assignee: | nobody → kernel-team |
status: | Unconfirmed → Needs Info |
Changed in linux-source-2.6.20: | |
status: | Needs Info → Confirmed |
importance: | Undecided → Medium |
Changed in linux-source-2.6.20: | |
assignee: | kernel-team → ubuntu-kernel-team |
Changed in linux: | |
status: | Unknown → Fix Released |
Changed in linux: | |
importance: | Unknown → Medium |
This issue seems to be that you are doing it on an encrypted filesystem. The kernel obviously has to perform a lot of IO intermixed with computational overhead to do this.
I don't know if the performance problem is expected or not. It all depends on what encryption method you are using, etc.