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

Bug#381135: crypto installs in german, french, spanish

tags 381135 +pending

On Wed, Aug 02, 2006 at 03:42:15PM +0200, Max Vozeler wrote:
> I also noticed one thing related to wiping partitions in
> preparation of encryption: The progressbar shown while
> blockdev-wipe runs was wildly inaccurate. It proceeded to 100%
> very quickly and then remained there for close to ten seconds.
> Overall the wipe seemed to complete too quickly compared the
> speed that this old harddisk is capable of (~3MB/s). I'll
> reassign this to partman-crypto and investigate.

The reason for the inaccuracy appears to be that the kernel
queues writes in memory and returns from write() long before the
disk can actually carry out the write. The queued writes are
normally flushed to disk once the device is close()ed, which
probably explains why it remains at 100% for so long.

In the course of testing this in- and outside d-i, I noticed
some peculiarity related to the OOM problems we've been seeing.
When writing to dm-crypt/loop-AES on a slow disk (no swap),
blockdev-wipe managed to trigger an OOM condition even on systems
with plenty of free memory (128MB, 94MB free). This did not
involve any tmpfs, so my handwaving theory ;-) is that the queued
writes took the system very close to OOM, then some allocation
request comes in, can't be statisfied and causes OOM.

Anyways, I've experimented with O_SYNC in order to force direct
flushes to disk. This helps to provide accurate progress
information and at the same time happens to cure/work-around the
OOM problem in pratice, to the point that I've been able to
complete multiple installs with 64MB, where previously OOM was
reliably triggered during erase.

The only downside to O_SYNC: There is a non-negligible impact 
on the disk performance. The kernel can no longer combine lots of
small requests into few larger ones. I have tested just how bad
this is on three separate systems and found that using a larger
blocksize of 64k can reduce the slowdown to 0-47% depending on
bus/disk/somethingelse. In particular, testing with an old IDE
disk showed no slowdown at all, while a newer disk connected
through USB 2.0 saw about 47% slowdown in the worst case.

Overall I think using O_SYNC is a good idea. I think the
performance hit is bearable and sure beats having to face the
oom-killer ;-) We might want to revisit this point sometime in
the future: Perhaps O_DIRECT or O_SYNC | O_DIRECT can provide
further speed improvements, or maybe it will no longer be
necessary to work-around the OOM problem. 

SAMSUNG MP0603H connected through USB 2.0
Device /dev/sdb1: 1953151 512-byte blocks

blocksize 4k         cur  sync 
  clear               39  151  (+ 287%)
  dm-crypt(aes,128)   59  164  (+ 177%)
  loop-AES(aes,128)   58  165  (+ 184%)

blocksize 64k        cur  sync 
  clear               39   46  (+ 17%)
  dm-crypt(aes,128)   59   87  (+ 47%)
  loop-AES(aes,128)   58   75  (+ 29%)

(All times in seconds, average of five runs)
SEAGATE ST31220A connected through IDE, mdma2
Device /dev/hdc2: 1124550 512-byte blocks

blocksize 4k         cur  sync
  clear              218  218  (+ 0%)
  dm-crypt(aes,128)  219  219  (+ 0%)
  loop-AES(aes,128)  220  220  (+ 0%)

blocksize 64k        cur  sync
  clear              230  218  (- 6%)
  dm-crypt(aes,128)  219  218  (- 1%)
  loop-AES(aes,128)  223  219  (- 2%)

(All times in seconds, average of five runs)

Reply to: