On 07/09/2017 05:18 PM, enh wrote:
> > On 07/09/2017 02:41 AM, Rob Landley wrote:
> > > does anybody have a decent strategy for testing the ibs
> > > and obs options?
> >
> > 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 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=?
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.
I say this because SIGSTOP/SIGCONT used to cause short reads, and the
interrupted read returned the data it had gotten when you continued.
(Yes, I had builds break because I suspended and resumed them, and root
caused it.)
The really annoying part was it would cause _zero_ length reads which
didn't mean end of file, you had to check errno for EAGAIN to
distinguish that. I think the kernel guys fixed it so it won't do that,
but if you SIGSTOP something that's doing a 1G single read() and then
SIGCONT what happens these days?
Hmmm...
$ cat > richards.c << EOF
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
printf("len=%d\n", read(0, malloc(1000000000), 1000000000));
}
EOF
$ gcc richards.c
$ ./a.out < coderush.mp4
^Z
[1]+ Stopped
$ fg
len=318818698
Oh that's just spectacular. The SIGSTOP doesn't take effect until the
read system call returns, even if it's reading 300 megs from rotating
media. Thank you SO much linux guys. (Having done a couple runs with
drop_caches I can confirm that ctrl-C doesn't work until the syscall
returns either. That's just beautiful. Obviously that's never going to
cause a problem ever, driving a system deep into swap thrashing... Reads
from local disk block in D state now?)
$ ./a.out < /dev/zero
^Z
[1]+ Stopped
landley@driftwood:~$ fg
./a.out < /dev/zero
len=96399360
Right, at least THAT still behaves like I expected. So SOMETIMES reads
will be shortened by suspend/resume cycles. And other times they block
in D state. (Yay inconsistent behavior!)
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?
Rob
_______________________________________________
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
