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

Les Mikesell <[email protected]> wrote:

> 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

I am sorry, but "tar" does not support incremental backups.

star does and star currently supports backups of filesystems.


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

----> man star

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

It should do as star (from what I know) is the only tar implementation
that uses a hashed list instead of a simple linear list.


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

I demanstrated yesterday that this is not true....

And please try not to confuse tar with GNU tar.

GNU tar is not tar and before GNU tar 1.15.1 was out, GNU tar
was not even be able to read/write tar compliant archives :-(



> it does not depend on any particular filesystem boundaries
> for the run or subsequent restore or any restrictions on

Please do not confuse a true incremental backup (which is done
on a whole filesystem and includes _all_ file metadata)
with a simple tar driectory tree archive.


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

GNU tar could absolutely not be called rubust - it fails miserably
even with simple backup test cases.

Before we start to compare star's method with another method,
please let us first check whether the other method has been implemented
in a correct way before. GNU tar's incrementals doe not work correctly 
so it does not make sense to compare them to useable programs
like ufsdump/ufsrestore or star.

BTS: star's method is much more robust than udsfump/ufsrestore.


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

As I did write more than once, this is not a problem with
star's incremental backup/restore.

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