svn commit: r191677 - head/usr.bin/du

[Bruce Evans]

On Thu, 30 Apr 2009, M. Warner Losh wrote:

> In message: <20090430110739.682cc989.stas at FreeBSD.org>
>            Stanislav Sedov <stas at FreeBSD.org> writes:
> : On Thu, 30 Apr 2009 16:36:38 +1000 (EST)
> : Bruce Evans <brde at optusnet.com.au> mentioned:
> :
> : > On Thu, 30 Apr 2009, Warner Losh wrote:
> : >
> : > > Log:
> : > >  Report the next directory being scanned when a ^T is pressed (or any
> : > >  SIGINFO).  Provides some progress report for the impatient.
> : >
> : > The impatient should use a tracing utility instead of encrufting
> : > individual utilities.
> :
> : On the other hand, using tracing utilities is not the best way to retireve
> : status information in all cases.

It just handles many more cases better than encrufting utilities does.

> Especially if one started the job and then it seems to be "stuck".
> It is most efficient to know if something is going on, and ^T gives
> that with a very minimal set of code.

No, this case is handled almost identically for utilities (like all the
encrufted ones starting with cp) whose activity consists mainly of making
syscalls -- both will report no output.  The tracing utilities should be
able to better when started with -p pid by determining if the process
is in a syscall (blocked or not) on startup.

Testing processes blocked in sleep(100) shows some bugs in truss(1):
- under ~5.2, truss without -p doesn't report the nanosleep() syscall
   until after 100 seconds, while ktrace without -p (plus kdump to watch)
   reports the syscall as soon as it is made followed by syscall return
   100 seconds later.  I think truss only reports syscall completion,
   so it works less well than ktrace for watching blocked syscalls.
- under ~5.2, both truss and ktrace/kdump with -p report the completion
   of the syscall after 100 seconds.
- under -current, truss with -p is broken.  It now aborts the nanosleep()
   immediately with EINTR.  ktrace with -p still works correctly.

> Tracing utilities produce way too much output...

This is a feature.  Instead of being restricted to the output that has
been encrufted, you can get fairly complete details of non-internal
(i.e., syscall) activity and filter out the parts that you don't want
to see.

Of course, large utilities with lots of internal state that might be
interesting to follow cannot be handled well by either ^T or tracing
utilities.

I hestitate to point out that your patch could be made less encrufted
and more useful by making it toggle the -v flag.  It could be made
more encrufted and more useful by subverting ^T further to cycle through
various combinations of flags, in particular -i for cp and rm.  Toggling
-i would fix the missing interaction of turning off -i in -i mode itself
Full encruftion would add GUI interaction to all the little utilities,
making them perfectly large and un-unixlike.

Bruce