Re: Perfomance problem backupscript (more details and tests)

Les Mikesell <[email protected]> wrote:

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

I would love if you could tell this to the Linux Kernel developers ;-)



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

In theory this could be done with star too, but I am not sure whether this
makes sense. 

First star-1.5-final needs to be published to have a "stable" alternative to
ufsdump/ufsrestore, then I would need to check what people like to do with
their backups..... The star archive format definition allows to store enough
information so that in theory a backup (that crosses mount points) could be
done. For the restore, the database format would need to be enhanced but this
is a transient format anyway.

But the problem is that GNU tar claims to support this kind of backups but
has too many bugs with incremental backup/restore to make it useful. 

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

gtar -cf /dev/null --totals sparsefile 
Total bytes written: 153600 (150KiB, 62MiB/s)

gtar -cf /dev/null --totals -S sparsefile 
gtar: sparsefile: Cannot seek to 0: Bad file number
Total bytes written: 153600 (150KiB, 59MiB/s)
gtar: Error exit delayed from previous errors

and BTW:

gtar -cf /dev/zero --totals -S sparsefile 
Total bytes written: 71680 (70KiB, 2.1MiB/s)

This is 1.15.1

Jörg

-- 
 EMail:[email protected] (home) Jörg Schilling D-13353 Berlin
       [email protected]		(uni)  
       [email protected]	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily