[Toybox] dd tests for transaction size?

[Rob Landley]

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?

Rob