On 07/09/2017 05:39 PM, Samuel Holland wrote:
> On 07/09/17 17:07, Rob Landley wrote:
>> Has anybody actually used the conv=sync option in the past 20 years?
>> It doesn't do what you think (that's conv=fsync), instead it pads
>> short reads with zeroes so the input block size is always the same.
>>
>> How is that useful?
> 
> It's very useful when trying to image dying hard disks, so bad sectors
> (that cause short reads or read failure) do not affect the alignment of
> the rest of the data in the image file.

Does the read failure automatically advance the file pointer by the full
amount, or does it have to lseek after the read? (I'm assuming the
first, but that's an implementation detail I have so many questions
about. I'm assuming your read block size is the device physical block
size, and thus the short read isn't skipping data after the missing data
which you otherwise could have read but gets turned into a short read
because the read would otherwise have holes in it? How do you
distinguish older 512 byte blocks from modern 4k blocks from whatever
the heck flash block sizes are? I assume there's an ioctl() or something
to find this out? Or do you just always use 512 bytes and hammering away
at different parts of the same bad block eventually makes its way out
the far side?)

Rob
_______________________________________________
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Reply via email to