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