Re: Re: Perfomance problem backupscript (more details and tests)

On Fri, 2005-10-07 at 07:13, Joerg Schilling wrote:

> Star relies on halfway standard compliant filesystems.

And for incrementals it depends on not crossing
filesystem boundaries, unlike any other version of
tar, and I think also on not using exclusions or
using exactly the same exclusion list.  These are
reasonable limitations considering the way it works
but surprising for something that looks and feels
like tar instead of dump.   And you have to deal with
the dumpdates files somehow if you have more than one
concurrent 'set' of full/incrementals running.  Do you
have a concise and exact description of the requirements
for incremental mode to work properly - including the
fact that the restore must also be to a single filesystem?

> > fixed inodes and the ability to create hardlinks by
> > having any number of directory entries pointing to the
> > same inode.  Backup methods must be able to re-create
> > these hardlinks - which isn't easy because all they
> > have in common is the inode number.
> 
> If the source filesystem you like to archive does not support
> hard links, this is absolutely no problem for star.

Actually one filesystem I'd like to archive has millions of
hardlinks and nothing else I've tried can copy it in
a reasonable length of time.  Does star handle the
matching efficiently?

> > Tar only cares if you do --listed-incrementals, and then it
> 
> Tar definitely does not have a --listed-incrementals option.

OK - --list-incremental, and only gnutar has this option.

> > only cares that the directories have the same inode
> > number on each pass (or the fake computed equivalent)
> > for the directories.  If they don't match, the failure
> > mode is to copy everything which is probably the best
> > way to fail.
> 
> I never tried to completely understand the GNU tar method
> and it is unclear whether this method may work correctly at all.

It does work correctly as long as the inode numbers are
consistent between runs.  And as you expect with tar,
it does not depend on any particular filesystem boundaries
for the run or subsequent restore or any restrictions on
exclusions.  Also, my guess would be that without LVM
snapshot support it is more robust on a live filesystem
than dump or star's method.  That is, the things that
go wrong due to changes during the backup run would be
less drastic with gnutar's approach.

> > ReiserFS doesn't completely follow unix semantics.
> 
> If you like to talk to UNIX semantics in crontrary to
> POSIX semantics,

I think the issue here is whether POSIX requires a ctime
change on a rename.  Original unix did not have an atomic
rename and thus it was impossible to change a name without
temporarily changing the link count, but when this changed
was a POSIX requirement added to update ctime when the
name of a link changes?

-- 
  Les Mikesell
    [email protected]