On Mon, Jul 10, 2017 at 10:57 AM, enh <e...@google.com> wrote: > 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...
actually, only one user seems to be setting bs=. everyone else has ibs=. >> Rob > > > > -- > Elliott Hughes - http://who/enh - http://jessies.org/~enh/ > Android native code/tools questions? Mail me/drop by/add me as a reviewer. -- 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
