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

[Andreas Dilger]

On 2010-03-25, at 14:36, Phillip Susi wrote:
> On 3/25/2010 4:22 PM, Eric Blake wrote:
> > To prove that this is wrong, you would have to point to a place in  
> > the
> > POSIX specification that forbids similar behavior for pax(1); I  
> > cannot
> > find such text.  Lacking proof that it is wrong, I agree with  
> > Sergey's
> > stance that it matches the documentation, and that changing it now  
> > would
> > be a mistake.
>
> You do not need a standard to explicitly forbid something for it to be
> wrong.  For instance, POSIX doesn't say anywhere that pax may not  
> delete
> half your files and rename the other half to random strings.
>
> Show me any other utility that silently fails to perform its primary
> function when you connect stdout to /dev/null.


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.

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).

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?

Cheers, Andreas
--
Andreas Dilger
Principal Engineer, Lustre Group
Oracle Corporation Canada Inc.