[Bug 82528] Write load on DM-Crypt LUKS partition with reiserfs jams system

Ulrich Lukas ulrich.lukas at tu-harburg.de
Fri Mar 16 20:09:13 UTC 2007


Public bug reported:

Binary package hint: linux-image-2.6.20-5-generic

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/testfile'
'destination'  "  with a testfile of 1GByte random data.

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-2.6.20-5-generic).

** Affects: linux-source-2.6.20 (Ubuntu)
     Importance: Undecided
     Assignee: Ubuntu Kernel Team
         Status: Needs Info

-- 
Write load on DM-Crypt LUKS partition with reiserfs jams system
https://launchpad.net/bugs/82528




More information about the kernel-team mailing list