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

Les Mikesell <[email protected]> wrote:

> On Thu, 2005-10-06 at 06:14, [email protected] wrote:
>
> > as we are discussing incremental backups :
> > 
> > Do i perceive it right that both star and GNU-tar rely on
> > the persistence of inode numbers within filesystems ?
>
> I think star relies on unix-like filesystem.  Tar does
> use device/inode combinations to track directories
> traversed by the full runs.

Star relies on halfway standard compliant filesystems.

But even a decent implementation is a microsoft filesystem
meets that criteria.

BTW: tar does not deal at all with device/inode combinations.
It may be that you confuse tar with GNU tar....


> On unix-like filesystems with valid ctimes all you need
> is the ctime of ordinary files since that catches any
> possible change - including ownership and permissions
> which your method appears to miss.  The problem is a
> renamed directory containing old files.

See man star -> INCREMENTAL BACKUPS

However, star wil be happy even if a rename of a file
does not retain the inode number but a rename of a directory 
retains the inode number of the directory _and_ the inode
numbers of all files inside the file tree of that directory.


> > (Thanks to inspiration by star, i added an alternative
> > inode-number check which runs fast and reliable on ext2
> > and reiserfs. Other types have still to be evaluated
> > but i guess it is ok with most locally attached 
> > filesystems on Linux.)
>
> Any filesystem with native unix semantics must have

This is not a UNIX only feature but this is required by
POSIX. Even microsoft follows the rules. The only problem
with the NT-FS (before POSIX.1-2001) was that the inode 
numbers from NT-FS need more than 32 bit but POSIX versions
before POSIX.1-2001 did not allow basic OS types to need more
than the size of a "long int".

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


> Tar only cares if you do --listed-incrementals, and then it

Tar definitely does not have a --listed-incrementals 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.


> > On my SuSE 9.0 the situation is nicely mixed :
> > 
> > mv changes ctime on ext2 but not on ReiserFS.
>
> ReiserFS doesn't completely follow unix semantics.

If you like to talk to UNIX semantics in crontrary to
POSIX semantics, then the only difference is that
UNIX has directories with a hard link count that is
2 + the number of sub directories inside the directory
(but this only in casee the directory is not hard linked
to another directory.

This is the reason why GNU find does not work correcly 
on almost any filesystem if you don't use gfind -noleaf
and fails always in case that a UNIX filesystem has hard linked
directories.

For the rest please let us talk about POSIX semantics and the
only problem misrosoft has with their filesystems is that
they are not case sensitive. The missing case sensitivity may
cause problems with star's incremental restore, but only if
the _target_ filesystem of an incremental restore is a MS
FS.



> Dump/restore used the same technique forever, but it is
> fairly intimate with the filesystem and it will fail
> horribly if you convert a directory to a mount point
> between runs.

star uses the same basic method as ufsdump/ufsrestore but
in a portable, OS and FS independent way.

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