Re: [Bug-tar] Tar cheats when directed to /dev/null

[Phillip Susi]

On 3/25/2010 6:02 PM, Andreas Dilger wrote:
> Umm, "gcc -O" will "silently" optimize away of your computations into
> nothing if the program being compiled doesn't actually do anything in
> the end (e.g. runs in a busy loop incrementing a counter whose value is
> never used in the program).  I don't see that tar "optimizing" the fact
> that you are asking it to throw away all of your output as being as
> totally wrong as you claim, though it is somewhat misleading.

And that's exactly what -O is supposed to do: optimize.  There is no
optimize or do not optimize flag to tar.  There is a reason why gcc has
-O0 and why -O2 is not the default.  You get very confusing results
trying to debug a program with -O2.

> Yes, I've been burned by this "feature" myself in the past and had to
> strace tar to figure out what is happening, but the question is whether
> using "tar" as a benchmark is really its "primary function".  Note that
> writing to /dev/null is NOT the same as writing to a real disk, so using
> that as a benchmark is misleading at best.  Writing to a real disk will
> double your memory traffic, double your IO bus traffic, add waits for
> real disk IO, and increase CPU usage, so the fact that you contacted
> this list after only a day's worth of head-scratching could be
> considered a feature, since you might have spent weeks collecting
> performance data only to find out your backup is only 1/2 as fast as you
> thought it would be...  (and I'm only half joking).

And that's exactly why I wanted the output going to null: so as not to
slow down the reading.  When I say cat file > /dev/null, I mean read
that file and write it to /dev/null.  I expect any side effects that
would have, such as updating atime, to take place, not be "optimized"
out.  I also expect it to behave (almost) the same as cat file | dd
of=/dev/null.

> Having tar write a message to stderr like "tar: discarding output
> written to /dev/null" would at least be less surprising, but I don't
> know if this has any usability impact for Amanda (which is AFAIK the
> reason this went in).  Perhaps it would be prudent to contact them and
> advise them of this change in advance, and then commit the change in a
> year or so?

Sure, that works... and if Amanda really wants a size estimate, it
should be replaced with a --estimate-size switch or similar.  Say what
you mean, and mean what you say; don't rely on some "optimization".