imalone: >> How would you go about estimating a decent blocksize (other than by >> testing)? My first instinct would be to go for some percentage of >> the drive's cache. Jacques B: > Available RAM. Use as big a block size as can possibly be read into > RAM (once you start caching to a drive you just as well be writing to > the destination drive otherwise you slow it down even more). We > played around with this a while back and it certainly makes a > difference (stands to reason as was already explained). > > The one caveat would be if there are errors on the drive. If that is > the case, a full block is dropped (so if your block size is 4096 > bytes, then 4K gets dropped instead of 512 bytes - now imagine > dropping a 256 meg block of data...). ddrescue will use two block > sizes - a larger one and a smaller one. If it hits an error it drops > back to the smaller one until it gets pass the error and then ramps > back up to the larger block size. I had a little play around with blocksizes for dd a while ago, while zeroing a drive (I was zeroing out a bad drive to see it it'd goad the drive into automatically sorting out the bad blocks, by itself - it did). The first attempt just started out using the default, and that took ages. After a bit of fiddling, I settled for using about a meg. Of course my situation was a bit different, but it's to show that you'd tweak the option to suit your circumstances. -- [tim@bigblack ~]$ uname -ipr 2.6.22.4-65.fc7 i686 i386 Using FC 4, 5, 6 & 7, plus CentOS 5. Today, it's FC7. Don't send private replies to my address, the mailbox is ignored. I read messages from the public lists.
