> I am no filesystem expert, but no filesystem seems to be using a block
> size smaller than 1024 bytes. So using 512 as a default for ddrescuelog
> does not seem to be useful.
FAT comes to mind, but besides floppy disks which are ancient enough
it's probably only found using 512-byte sectors on really old hard
disks. So yes, if ddrescuelog is primarily meant to output a list of
damaged file system blocks then 512 byte would be a seldomly used
default. However, I used to think of ddrescuelog as a more low-level
tool, i.e. working on the same (hard disk block) level as ddrescue. For
instance I use it to generate lists of bad sectors (512 byte) without
any regard for higher-level structures like file systems.
As I said before I don't really care all too much about the default
value. Not to mention people may already have written scripts with the
old 4 KiB default that would stop working if the default was changed now.
One more thing to take care of, though: Imagine you first use ddrescue
and there is one bad block (512 byte) surrounded by successfully read
data. Using ddrescuelog's new --change-types option to i.e. invert the
block types together with a default 4 KiB block size, would that turn
the 3.5 KiB surrounding the bad block into the same block type as the
bad block? Or vice versa? Or are block boundaries and thus block sizes
completely ignored by --change-types?