Jan Johansson wrote: > cookiemonster:~# head -c 15 /dev/urandom | uuencode -m - | head -n 2 | > tail -n 1 | losetup -p 0 -e AES256 /dev/loop1 /dev/md2 You set up loop1 device. Ok so far. > cookiemonster:~# dd if=/dev/zero of=/dev/loop3 bs=4k conv=notrunc > 2>/dev/null But here you are writing to loop3 instead of loop1. What does loop3 contain, and what gets overwritten here? Maybe loop3 was uninitialized zero length device, so effectively nothing was written anywhere. > Mar 9 20:32:46 cookiemonster kernel: Out of Memory: Killed process 4256 > (mysqld). [snip] > Mar 9 20:31:58 cookiemonster kernel: swapper: page allocation failure. > order:0, mode:0x20 Kernel is running out of free RAM. Someone completely depleted kernel's free RAM pools. Even emergency pools are gone (mode:0x20 == __GFP_HIGH). Device backed loop-AES does not allocate any RAM at run time. All RAM that it needs is allocated at losetup/mount time. To me this looks like the kernel code that sends write requests to loop device depletes kernel RAM pool by agressively allocating RAM pages to hold the data to write. Loop driver will queue all writes thrown at it, so that significant portion of RAM pages are queued waiting to be written to underlying device. There is something strange going on in your kernel's RAM allocation code. Have you set any strange values to /proc/sys/vm/* files? Any values set in /etc/sysctl.conf file? -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
