[Toybox] dd tests for transaction size?

[enh]

On Mon, Jul 10, 2017 at 10:46 AM, Rob Landley <rob at landley.net> wrote:
> On 07/10/2017 12:15 AM, enh wrote:
>> On Sun, Jul 9, 2017 at 4:23 PM, Rob Landley <rob at landley.net> wrote:
>>>> It's used in various boot disk generation scripts in the Android tree.
>>>> (Whether it's needed is a question I can't answer as easily!)
>>>
>>> Hang on, do you use sync= or fsync=?
>>
>> the only code owned my either of _my_ teams uses conv=fsync. but a
>> search for conv=sync turned up _more_ references to conv=sync than
>> conv=fsync.
>
> Is there a Gratuitous Gnu Extension for this...?
>
> Hmmm, conv=sparse seems useful.
>
> How is conv=excl _not_ oflag=excl? In what world did that make sense?
> (Alright, nocreat and notrunc were already there. I guess that one's on
> posix.)
>
> WHY does ubuntu's dd parse zeta or yottabyte extensions? A signed 64 bit
> number is 4 exabytes, do they expect 128 bit math here? (Do they expect
> _filesystems_ that can field that much data? Most of the distributed
> filesystems work on top of fuse which enforces a _signed_ 64 bit off_t,
> again 4 exabytes...)
>
> Nope, there isn't even a gnu extension for this. Lovely.
>
>>> Because sync= pads _all_ short reads to block size with zeroes, not just
>>> the last one. I can see this being used to pad the _last_ block with
>>> zeroes, but it sounds like it could also corrupt the data if there are
>>> short reads before that.
>>
>> the users that had comments said they wanted the last block padded.
>> padding all short reads (including EINTR ones) seems insane.
>
> I thought so, yes. Alas, implementing this thing to only pad the _last_
> block seems...
>
> Hmmm. Maybe I could tie this to the already fiddly posix bs= behavior.
> If you specify bs= instead of ifs= and ofs=, then it does the normal
> "write out what we got" and only pads the last block. If you specify
> ifs= then it pads each input block.
>
> I'd poke the posix committee about this but after
> http://article.gmane.org/gmane.comp.standards.posix.austin.general/12203
> I've stopped expecting that to accomplish anything.
>
>>> Sigh. I suppose android builds are always happening from local disk (not
>>> network filesystems) and are never suspended during a build, so you
>>> don't need to worry about it?
>>
>> i suspect that's why no-one notices the insanity. (when we first
>> started using the gold linker elsewhere in google i had to fix its
>> EINTR behavior. happens all the time on a FUSE file system, but folks
>> had been using it for years on regular file systems without noticing.)
>
> Yeah, I have readall() and writeall() in lib to loop for me. (Back in
> busybox I had code checking for EAGAIN but the kernel guys convinced me
> we shouldn't get _zero_ length reads except at EOF now? Alas googling
> for this discussion is not finding it, and it's once again one of those
> "but did I test on _v9fs_?" sort of things trying to prove a negative
> myself.)
>
> Would the above bs= behavior tie sound like it would work for the users
> you found?

for what the comments claim, yes, but i'll track one of the clueful
users down and check with them...

> Rob



-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.