Bug#381135: crypto installs in german, french, spanish
tags 381135 +pending
thanks
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.
cheers,
Max
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: