Paul Fox wrote:
> > > tar -cvf /dev/null
> > >
> > > the tar to /dev/null actually doesn't take that long at all, maybe a few
> > > minutes depending on the size.
> >
> > Gnu tar actually recognizes if stdout is connected to /dev/null (even if
> > you redirect instead of specifying -f) and doesn't bother to read the
> > file contents. I think that was an optimization intended to be used
>
> aaaargh. that's absurd. are you sure? it would completely eliminate
> any usefulness of /dev/null.
>
> i once heard a similar (and possibly apocryphal) story about some
> CPU h/w engineers that thought they were doing the s/w folks
> a favor by making the NOP instruction take zero time. :-) not
> sending output to /dev/null makes just as much sense.
Yes but it is specific to gnutar not anything general. Try timing:
tar --totals --one-file-system -cf /dev/null /
or
tar --totals --one-file-system -cf - / > /dev/null
vs.
tar --totals --one-file-system -cf - / |cat > /dev/null
Next to none of the difference comes from the overhead of running 'cat'.
The feature does make sense, especially if you run amanda - she is smart
enough to adjust the full/incremental mix to fill a tape every night and
still get at least some incremental level of every machine if it can
possibly fit. But, I agree that it would have been cleaner to add an
explicit option instead of magically detecting a connection to
/dev/null. Some people have probably done timing tests and think their
disks can actually read that fast...
--
Les Mikesell
[EMAIL PROTECTED]
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
BackupPC-users mailing list
[email protected]
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
