[Toybox] dd tests for transaction size?

[Rob Landley]

On 07/11/2017 06:37 AM, Samuel Holland wrote:
> On 07/09/17 18:25, Rob Landley wrote:
>> 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 don't know the implementation details.

I kinda need to know the implementation details. :)

That said, I'm assuming I don't have to do anything special because dd
wasn't written initially to care about this behavior, and that's just
what happened when it did the simple thing, and your trick was adapted
to what it was already doing, not the other way around. :)

>> 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?
> 
> Everything within ibs past the point of failure is replaced with zeroes.
> So if the ibs=16k and your third 512b sector is bad, you'll have 1k of
> good data followed by 15k of zeroes, even if the rest of the sectors are
> okay. If you want to maximize the amount of data retrieved, then yes,
> you want ibs=sectorsize. If you want to quickly find good/bad areas of
> the disk, then ibs can be larger.

Ok, so you're micromanaging your call to it, and again dd's
implementation doesn't have to be clever.

>> 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?)
> 
> I take the disk out of the machine and look at the label :) If it has
> the "AF" logo, it's 4k sectors, otherwise it's 512b. There's also an
> ioctl: `blockdev --getbsz /dev/sda`. In my experience, flash storage
> doesn't get bad sectors; it works until it doesn't.

Ooh, we even have a blocksize in toybox already. (People send me these
things, I scrutinize them to make sure they work, but I don't always
remember "shred" or "acpi" exists until somebody brings it up. :)

(The acpi command's -V option seems to think my netbook's lcd has a
cooling fan. This is an option?)

Rob