Re: Perfomance problem backupscript (more details and tests)

Les Mikesell <[email protected]> wrote:

> On Tue, 2005-10-11 at 06:17, Joerg Schilling wrote:
> > > > > The point of that test was to show that GNU tar does handle
> > > > > renamed directories correctly with --listed-incremental.
> > > > 
> > > > It definitely does _not_.
> > > > 
> > > > Try to get the most recent release (1.15.1) compile it by your own
> > > > and follow the instructions I did send out last week.
> > >
> > > My test script works the same and duplicates the contents of the
> > > renamed directory with 1.15.1.  I can't use your instructions because
> > 
> > Did you repeat the test with a _real_  1.15.1?
>
> Yes, simple directory renaming is handled by all versions. There
> are other bugs, and perhaps a design flaw that can't be fixed
> in a backwards compatible way:  the GNUdump format archive that
> is created contains only the filenames present in a directory
> and no indication of its type.  That means that a directory
> replaced by a file of the same name is not automatically
> removed in the directory pass (because the name existed
> at incremental time)  and it also is not overwritten in the file restore
> step (it needs the equivalent of star's -force-remove,
> -remove-first, and -remove-recursive options to work around
> this).  Fortunately the data is still in the archive and
> can be restored if the offending directory is moved so it
> is less problematic than star's somewhat equivalent problem
> if you migrate the contents of a directory to a new filesystem
> mounted on that directory between runs. 

There you see the advantage of star's dump format that not only 
includes the names inside a directory but also the inode numbers.

In case that you are interested: one of the tree minor problems I had
with star's incremental restore algorithm was that a removed directory
may free an inode number that then in turn is reused for a file
of different type but the same name. As star knows the old type from
a stat(2) on the current restore state and the new file type from the
current meta data inside the star incremental, star is able to 
deal with this case.

Note that in case that a filesystem does not implement persistent inode
numbers, the content of a renamed directory will _not_ be in the
GNU tar incremental.


> > If the version you use has some of the named bugs fixed, then the followoing
> > applies to you:
> > 
> > -	You are using a badly maitained distro as it seems that the maintainer
> > 	do not care about star the same way as they do for GNU tar.
>
> The maintainers do updates as possible for bugs that users report,
> so this really means that it is the users that don't care about
> star.  Since star has command line syntax that is incompatible
> with any existing backup manager and a little-understood
> mechanism for incrementals, it is not surprising that it is
> used less.  If you'd like the fedora maintainers to update star
> please file a bugzilla report on the problem that needs to
> be fixed.  Behavior-changing updates are left for the next
> OS version release.

Then please tell me why GNU tar is used although it's command line syntax
does not meet the command line syntax of other tar implementations?

Tell me why people complain that star's syntax is supposed to be incompatible
to tar while it is only incompatible to GNU tar?

I believe that this is caused by the fact that Linux users are not
very flexible and tend to believe that Linux programs are all bug free
even if they don't.

Star's behavior is not changed in an incompatible way (as it happens
with GNU tar), so I see no reason for not using recent version. Note that
star is the only way to backup ACLs on Linux....


> > -	You don't use a GNU tar-1.15.1 but an internal developer version
> > 	that does not have been published as an official version that
> > 	compiles on all platforms. Note that you cannot e.g. compile the
> > 	CVS content from the GNU tar maintainers on Solaris as the creation
> > 	of a useful GNU tar source archive depends on non-standard programs.
>
> I don't expect any application to work on all platforms until the
> distribution maintainers have adapted and tested it.  The patches
> may find their way into the base distribution eventually but
> I gave up on expecting developer releases to 'just work'
> everywhere long ago.  

Why then do you use internal developer releases of GNU tar?


> > > > Please be fair and compare the latest GNU tar version with the latest
> > > > star version.
> > >
> > > A fair comparison requires an equally widely tested version of star.
> > 
> > I am sorry, but I will not reduce the quality of star in order to meet your 
> > wishes.....
>
> How do you consider that adapting to plaforms and fixing user
> reported bugs reduces quality?

??? The problem with GNU tar is that dozens of Bugs Reports I did make in 1993
have been fixed in 2004. Do you call this reliable maintining an
important program like GNU tar?


> > -	It usually takes 10 years for the GNU tar maintainers to fix them.
>
> Which is fortunately offset by the fact that it has been used
> heavily for more than 10 years...

It it has been really heavily used, then other people would have had the 
same problems and did report it....

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