[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Andreas Dilger
Subject: Re: [Bug-tar] Tar cheats when directed to /dev/null
Date: Thu, 25 Mar 2010 16:02:58 -0600

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]