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)