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

[email protected] wrote:

> > I think star relies on unix-like filesystem.  Tar does
> > use device/inode combinations to track directories
> > traversed by the full runs.
>
> How does GNU-tar detect if a file vanished between
> two backup levels ?

It cannot. It asumes (during a restore) that if a file name
is no longer present this file was deleted although it may just have 
been renamed.

> To my theory, star does this when joining updated
> directories with the file bodies during restore.

Star detects and handles renamed files (inside a single directory) 
before it starts to extract that directory. All file names that
are no longer present in the new directory version but that
have not been renamed inside the same dir are moved to
/star-tmpdir.


> But how does GNU-tar remove obsolete files at restore
> time ? Does it delete the whole directory before restoring
> the new layer ?

It is not really clear, the code is hard to read and to understand.
Maybe this is why there are bugs inside.


> No idea. It's google hearsay. But very common one.
> I use ext2 and reiserfs on disk.
> But i was pointed to SMBFS when asking my users about
> their opinion on an inode-based content test.

If a SMBFS client does not implement inode numbers it is broken.


> > Any filesystem with native unix semantics must have
> > fixed inodes and the ability to create hardlinks by
> > having any number of directory entries pointing to the
> > same inode. 
>
> Users (the experienced and skilled ones) told me
> that they are uncomfortable with any reference to
> inodes.

Then they are not experienced enough....

Many programs need to deal with st_dev/st_ino pairs because this
is the only way to prevent killing files by copying them to itself.

> That is because inodes form a directed graph but the
> user model of data storage is a tree. Hardlinks are
> handy but introduce severe fundamental problems.

Irrelevent. The inode is just a file serial number and the usage
is the usage for a file serial number. People who try to set up
any topoligical model on inode numbers need to learn what they are for.

> > Backup methods must be able to re-create
> > these hardlinks - which isn't easy because all they
> > have in common is the inode number.
>
> Interesting point.
>
> I would agree to :
> "For situations where hardlinks do matter, backup methods
>  must be provided which allow restoring of hardlinks."

Of course! Did you believe otherwise?

> The problem with hardlinks is that they cannot be represented
> in common formats like ISO-9660. Offer a desktop user the 
> choice of having the personal backup in ISO-9660 or in tar
> and you will see a 90% majority for ISO. It's so handy
> for picking files after small mishaps.

Solaris will fix this ISO-9660 implementation problem soon....
ISO-9660 implements hard links but all currently known OS
implementations offer different inode numbers for the same file
then.


> So GNU-tar not only ignores the existence of inode-problematic
> filesystems but also the existence of SuSE 9.0 ReiserFS ???
> (It is the _default_ filesystem of the toadies.)

What should this mean?


> > All unix filesytems have ctime values that are updated
> > with any inode change. 
>
> When i started my own backup project back in 1999 
> Linux did not change ctime on rename. I was not amused
> but reading  man 2 stat  told me why this was the fact.
> There was only ext2 and ext2 is rustily based on inodes.

Linux is not the center of the world. You need to look at POSIX
and in nealy all cases you lvbe better if you implement and test
on Solaris because Solaris is much closer to POSIX than Linux.


> > 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.
>
> dump was a pain in the ass forever :((
> dump and DAT are the reason why i began to develop own
> backup software. :))

ufsdump/ufsreastore are 100% OK.

Dump/restore are hacks on ufsdump/ufsreastore and may not be correct.

DAT indeed is a pain in the a** and should be avoided for backups
because it is not reliable at all.

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