Re: Perfomance problem backupscript (more details and tests)

On Wed, 2005-10-05 at 11:08, Joerg Schilling wrote:
> >
> > For the pathological cases where I've wanted gnutar to read
> > data, then discard it, I've used  "-f - |cat >/dev/null".
> 
> This makes it slower as needed as you need to feed the pipe.

Perhaps, but I've never been concerned about how fast I could
discard data.

> > > It is really bad practice to introduce such an implicit and hidden
> > > feature into a program. Star does it the clean, obvious and easy
> > > to controllable way: use star -onull if you only like to do 
> > > specfic tests for size metering.
> >
> > On the other hand it is useless, even if good practice, to arbitrarily
> > change options so that interoperation with other existing tools
> 
> Amanda people did request an option and ware a bit disappointed when the
> GNU tar people implemented it this strage way....

A lot of things are done in strange ways, but after the infrastructure
around them is added it becomes counterproductive to invent arbitrarily
different ways, even if some people think they are less strange.

> > like amanda cannot work.  Star might now have sufficient
> > awareness of incrementals to replace gnutar for amanda runs, but
> > guess which I'm still using...   Are there any higher-level programs
> > like amanda, backuppc, etc. that work with star?
> 
> I am not aware of them but it seems that the Amanda people are very GNU tar
> centric althouth they know that GNU tar does not do what they like with
> incremental backups.

How do you mean that?  GNU tar does it about the only way possible that
permits backing up arbitrary directories where the recursion crosses
mount points and that allows multiple backup sets, each with their
own concept of when the prior run was done and, of course, catching
old files that are now under renamed directories compared to a prior
run.  It works with amanda and does what I like (the backup is correct),
and it seems there is no other choice.

> > > Note that GNU tar is even buggy in it's "amanda feature" and badly
> > > fails if you use this "feature" together with sparse files.
> >
> > Does it report the space as shown by ls -l, or what will be used
> > in the modes that understand sparse files?
> 
> Try it out..... There are strange error messages and GNU tar reports the
> same size as it would do without -S.

That doesn't seem to be true.  I have a bizarre test case on an x86_64
Linux box with
# ls -l /var/log/lastlog
-r--------    1 root     root     1254130450140 Oct  5 12:04
/var/log/lastlog
and 
tar --totals -cvf /dev/null .
gives:
Total bytes written: 1254684180480 (1.1TB, 106GB/s)
tar --sparse --totals -cvf /dev/null .
says:
Total bytes written: 553779200 (528MB, 79kB/s)
(and took forever to run so an amanda estimate would have failed
anyway but there were no error messages.

This is with gnutar 1.13.25.

-- 
  Les Mikesell
    [email protected]