On Mon, Jul 10, 2017 at 10:46 AM, Rob Landley <r...@landley.net> wrote: > On 07/10/2017 12:15 AM, enh wrote: >> On Sun, Jul 9, 2017 at 4:23 PM, Rob Landley <r...@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. _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
