Jari Ruusu wrote: > Jari Ruusu wrote: >> 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. > > Just to clarify this: Default soft block size is set to such value that full > device can be accessed using X amount of such soft block size chunks. File > system mount knows that it won't access any less-than-block-size leftovers > at the end of the device, so it can set to more sane value. > > In following examples, /dev/hdd2, /dev/loop3 and /dev/loop6 sizes are > interger multiple of 4096 bytes, and as such, can be fully accessed using > 4096 byte soft block size. /dev/hdd9, /dev/loop4 and /dev/loop5 are not, and > are accessed using 512 byte soft block size. Prior to mount, that is. > Meaning that any mkfs, fsck, and other direct access will not perform as > fast and efficiently as for /dev/hdd2, /dev/loop3 and /dev/loop6. After > mount, /dev/hdd2 and /dev/hdd9 should perform identically, as should > /dev/loop3, /dev/loop4, /dev/loop5 and /dev/loop6. > > # blockdev --getsize /dev/hdd2 > 102816 > > (device size is integer multiple of 4096 bytes) > > # losetup -e AES128 -K loop-AES/gpgkey3.asc /dev/loop3 /dev/hdd2 > Password: > # blockdev --getbsz /dev/loop3 > 4096 > > (default soft block size is 4096 bytes) > > # losetup -e AES128 -K loop-AES/gpgkey3.asc -o 512 /dev/loop5 /dev/hdd2 > Password: > # blockdev --getbsz /dev/loop5 > 512 > > (default soft block size is *LESS THAN* 4096 bytes) > > # blockdev --getsize /dev/hdd9 > 102753 > > (device size is *NOT* integer multiple of 4096 bytes) > > # losetup -e AES128 -K loop-AES/gpgkey3.asc /dev/loop4 /dev/hdd9 > Password: > # blockdev --getbsz /dev/loop4 > 512 > > (default soft block size is *LESS THAN* 4096 bytes) > > # losetup -e AES128 -K loop-AES/gpgkey3.asc -o 512 /dev/loop6 /dev/hdd9 > Password: > # blockdev --getbsz /dev/loop6 > 4096 > > (default soft block size is 4096 bytes) Thanks for the explanation. So i will through in a little Perl-Script, that makes sure that the "raw" loop (before it has a filesystem) has a soft-block-size of 4096, so that i won't have performance-problems when i work directly with a/the loop. (I can life with the few KB of lost space, i still have a great gain of several MB(*) because i don't have the partition-alignment "problem") But i still think that a little "note" about that is appropriate for the README, so that other won't fall into the same tarpit as i. :-) It's good that YOU know all that, but others don't know that. Especially as this topic isn't on the radar of, i'd guess, 99% of people. *: For the 200GB drives that i currently convert i have a net gain in capacity of about 100MB. One part "partition alignment" and one part "Smaller log-size of the recreated XFS filesystem". If i didn't misscalculate the total loss of capacity is about 5MB due to various overheads, mostly the filesystem itself. I think i can live with that. :-) -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
