Matthias Schniedermeyer wrote: > I discovered the slow performance while "initializing" the loop with > dd if=/dev/zero of=/dev/loop<x> > (Currently i'm not sure if i also used a bs=<whatever>, maybe not) When block device is accessed directly, kernel splits I/O to soft block size chunks. 'dd bs=<whatever>' is just for user space dd program, and does not affect what slitting happens in kernel. > I think the total capacity is quite irrelevant for this case, it's the > expected HDD size minus 8 Blocks? > blockdev --getsize /dev/loop2 > 976773160 (976773160 * 512) % 4096 == 0 > blockdev --getsize /dev/sdb > 976773168 (976773168 * 512) % 4096 == 0 Both device sizes are integer multiples of 4096 bytes. When you shrink the the device size by non-4096 byte amount, that is no longer true. 976773160 and 976773168 sector size devices can be fully accessed using 4096 soft block size. It is the default smaller soft block size that causes the slowdown. > performing "direct to loop" would also lead to a poorly performing > "filesystem over loop". Nope. If you test it using a file system, then file system mount of course sets better soft block size and bangs the device using more optimally sized reguests. # losetup -e AES128 -K gpgkey3.asc /dev/loop0 /dev/hdd9 Password: # blockdev --getbsz /dev/loop0 512 (partition backed inherits 512 byte soft block size) # mount -t ext2 /dev/loop0 /mnt # blockdev --getbsz /dev/loop0 4096 (but mount sets it to 4096 bytes, as it should) # umount /mnt # losetup -d /dev/loop0 # mount -t ext2 /dev/hdd9 /mnt \ > -o loop=/dev/loop2,encryption=AES128,gpgkey=gpgkey3.asc Password: # blockdev --getbsz /dev/loop2 4096 (4096 byte soft block size after mount, ok here too) -- 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/
