Which sector size shall I choose to run ddrescue with direct access on an Advanced Format drive

Even though the question was asked 10 months ago, the answer might be relevant because the recovery cycle might still be running depending on a few factors! No pun intended.

The reason is that, time estimate is almost impossible, however sometimes you could get a rough idea as follows. One of the most obvious reasons is that you can't predict how long it will take the drive to read a bad sector and if you want ddrescue to read and retry every single one, then it could take a very long time. For example, I'm currently running a recovery on a small 500GB drive that's been going on for over 2 weeks and I possibly have a few days left. But mine is a more complicated situation because the drive is encrypted and to read anything successfully, I have make sure to get all sectors that have partition tables, boot sectors and other important parts of the disk. I'm using techniques in addition to ddrescue to improve my chances for all the bad sectors. IOW, your unique situation is important in determining time to completion.

By estimate of "loops", if you mean number of retries then that's something you determine by the parameters you use. If you mean "total number of passes", that's easily determined by reading about the algorithm here.. >man ddrescue< / Algorithm: How ddrescue recovers the data

I'll specifically speak to the numbers in the screen captures you provided. Other situations may have other factors that apply, so take this information as a general guideline.

In the sample you've provided take a look at ddrescue's running status screen. We get the total "estimate" of the problem (rescue domain) by "errsize". This is the amount of data that is "yet to be read". In the sample it is 345GB. Next line below to the right is "average rate". In the sample it is 583kb/s

If the "average rate" was to remain close to steady, this means you have 7 more days to go. 345 GB / (583 kb * 60*60*24) = 7.18 However the problem is that you can't rely on the 583kb/s. In fact deeper you go into recovery, the drive gets slower since it's reading more and more tougher areas and is doing more retries. So the time to finish exponentially increases. All of this depends on how badly the drive is damaged.

The sample you've provided shows a "successful read" was over 10 hours ago. That's saying that it's not really getting anything from the drive for 10+ hours. This shows that your drive may have 345GB worth (or a portion) of data shot. This is very bad news for you.

In contrast, my second 500GB drive that had just started giving me "S.M.A.R.T" errors, was copied disk to disk (with log file on another drive) and the whole operation took about 8-9 hours. The last part of it slowed down. But that's still bearable. While the very bad drive, as noted above is well past 2 weeks working on 500GB and still has about 4-5 % remaining to recover.

HTH and YMMV

man blockdev

   --setbsz bytes
          Set blocksize. Note that the block size is specific to the  cur‐
          rent  file descriptor opening the block device, so the change of
          block size only persists for as long as blockdev has the  device
          open, and is lost once blockdev exits.

In block/ioctl.c:

case BLKBSZGET: /* get block device soft block size (cf. BLKSSZGET) */
    return put_int(arg, block_size(bdev));
case BLKSSZGET: /* get block device logical block size */
    return put_int(arg, bdev_logical_block_size(bdev));
case BLKPBSZGET: /* get block device physical block size */
    return put_uint(arg, bdev_physical_block_size(bdev));

So BSZ reported by blockdev is neither logical nor physical block size. It is the "soft block size".

Looking at this code, the part about soft block size being specific to the file descriptor does not appear to make sense. Nor does wanting to set that with blockdev, given that no other option is documented in terms of blocks (only fixed-size 512 byte sectors).

In my own tests, what actually happens is that BSZ is preserved for as long as any process holds the block device open. It looks like it gets reset on the last close().

Parted got confused by this too some years ago

belay that. BLKBSZGET is the kernel's chosen block size it will use to access the device (for normal disks turns out this is 1k, for ata_ram this is 4k), which is not the underlying disk's logical block size. :-( So we will likely need another ioctl() to get the right value from the kernel, and BLKSSZGET may wind up being the disks's logical block size, while a new ioctl() exports the disk's physical sector size. ugh.

Another quirk:

On Wed, Apr 09, 2003 at 06:53:17PM +0200, Rob van Nieuwkerk wrote:

I get 4096 with BLKBSZGET on several unmounted partitions on my system (RH 2.4.18-27.7.x kernel). Some give 1024 .. Maybe it is because I had them mounted first and unmounted them for the test ?

That would be the most likely answer. When you unmount, I don't believe the filesystem bothers to set_blocksize(get_hardsect_size(dev)).