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.
