Re: Perfomance problem backupscript (more details and tests)

On Wed, 2005-10-12 at 09:26, Joerg Schilling wrote:

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

I'm fairly sure you are mistaken about this.  Any mismatch of the
filed directory name/device/inode should result in all contents
being included.  It has been years since I looked at the code but
I'm fairly sure this concept has not changed.  The only assumption
is that a matching name/device/inode is not new or renamed and thus
needs only to observe ctime changes on contained files like a
normal '--newer DATE' run. On a mismatch or new entry, all content
is included regardless of timestamps. If no inode numbers matched,
the incremental run would essentially be the same as a full.

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

Other tars are irrelevant and have been since the original couldn't
take device special nodes. GNUtar is used because it is suitable for
full system backups and has had an incremental mode suitable for use
with amanda for many years.  But, since I didn't use the original tar
much, I can't think of any command line differences from the tar version
that existed when GNUtar was first written.  When the GNU extensions
came first, how could they be compatible with the ones not added to
non-GNU tar yet?

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

It will not work with amanda - or anything else that has been written
to use GNUtar's features.

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

No, this is precisely why distributions based on Linux have their own
package maintains. No one expects bug free code - they do expect
millions of users to find and report the bugs that matter though, and
in general that has been very effective. Even if there are bugs
there should be few surprises - and once a repeatable way to reproduce
a bug has been supplied it usually gets fixed.

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

I agree star has it's advantages.  I just wish I could use it by
replacing my tar with star and have the decade-old wrappers keep on
working.  How about an /etc/star.conf that can have an option to
force exact GNU tar syntax if you insist on a less popular default?

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

I don't.  I use the tested version included and updated for
the OS distribution - as I do for all the other programs
I run.  I don't like surprises.

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

That's very much irrelevant to me as long as the bugs are fixed before
they land on my disk.  I don't care if the developer's alpha version is
broken or not - I've generally come to expect that.
 
> > > -	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....

They did have problems, reported them, and they were fixed in the
version I use - as you can note by the seven patches in the maintained
package I mentioned earlier. The remaining bug is that a directory that
exists at the time an incremental (or any other) extract is done
containing a file of the same name is not removed, so the file creation
will fail.  This is only partly related to incremental handling.
Apparently people don't create files of the same name as earlier
directories often enough to trigger and notice this bug.

-- 
  Les Mikesell
    [email protected]