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

Question

I started the imaging of an AF/512e HDD by first running a following command:

    ddrescue -n /dev/sdb2 drive_c.img mapfile.log

Upon its completion I made a backup of mapfile.log and decided to run the splitting phase with direct disk access using the drive's physical sector size of 4K:

    ddrescue -d -b4096 -r3 /dev/sdb2 drive_c.img mapfile.log

Had I chosen a 512 bytes sector-size would I have scraped more from the bad sectors?

As I write this, the splitting stage has finished and the bad sectors are being retried for the second time. Naturally, almost all bad blocks in the mapfile are of n×4K size. Will I be able to scrape more off of them if I run the same command but with a 512 b sector?

Thoughts and Confusion

First of all, I am not even sure if the use direct disk access was appropriate.

The info file for ddrescue calls for direct disk access switch when

the positions and sizes in the log file are ALWAYS multiples of the sector size

which would mean that the

kernel is caching the disc accesses and grouping them.

So if my kernel had been "grouping" the requests, the smallest block in the mapfile should have been 8K or 16K. In my case, however, the mapfile contained plenty of 512 bytes blocks both unreadable and rescued after the first run had completed.

During the second run the majority of the 512 b blocks were merged into 4K blocks. For example, a 512 b bad sector which was adjacent to the non-split block before the splitting phase got merged together with an adjacent bad sector. This seems fine to me. Probably, at the trimming phase a head on the hard drive wasn't able to read a 4K sector so it returned a 512 b bad sector to ddrescue. The trimming ended right there, and the block following the 512 b sector was marked as a non-split.

What doesn't seem normal is having a 512 b bad sector like in this screenshot:

How come a head is able to read a 4K sector but declare only a 1/8 of it unreadable? I was under impression that a physical sector is read atomically by a head? So if a part of it is bad, the whole sector is bad.

This obviously raises a question -- is it possible to get data from a 4K "partially bad" sector by running ddrescue with or without direct access but with a 512 b sector size?

Obviously something doesn't add up.

BTW this is my first posted question so please excuse me if the format is not consistent with the forum or the question is too loaded. But that aside I would be grateful to get an input on any of the topics relevant to the main question i.e. Advanced Format, direct disk access, kernel caching etc. as everything I find is either too far from the case in point or clearly assumes expertise from the reader.

Cheers!

Answer 1

I've exchanged emails with the author of ddrescue, Antonio Diaz, and he told me that the correct parameter to use with an "advanced format" drive (i.e., a drive with 4096-byte physical sectors, but 512-byte "logical sectors") is:

 -b4096

If you wanted it to read just one 4096-byte sector at a time (slow!) then you would also specify:

  -c1

Antonio is not active on StackExchange, but he supports ddrescue via this email mailing list:

https://www.mail-archive.com/[email protected]/

If you send your email to [email protected] then your email will appear on that summary page, as will his answer, in nicely organized form (but without your email address shown, of course). Additionally, you may search on that page to try to find previous discussions of your issue or question, before bothering Antonio. (He is a very busy man, so please don't waste his time!)

The reason that your ddrescue logfile contains a 512-byte "bad" area is that you initially ran ddrescue with the default sector size of 512 bytes. That's not disastrous, but if ddrescue thinks the drive has 512 byte sectors, and a read is issued that returns 0 bytes of data due to a read error, then ddrescue assumes that only the first of 512 bytes are unreadable, and makes no assumption about the rest. So only 512 bytes is marked as bad in the logfile.

Answer 2

According to Wikipedia, parity can be distributed and ECC can recover some data. There may be different ECC algorithms for different disks. In the case of the 512-bit sector error, maybe the 4K sector was only partly damaged and the ECC was able to correct and validate 7/8 of the 4K sector.