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

Les Mikesell <[email protected]> wrote:

> It is probably very common now to use usb drives (both flash
> and real) and swap among systems.  I'd expect synthetic inode
> numbers to change if the contents are modified between mounts.

It is a well known implementation deficit of Linux.

Move to Solaris in case you have problems related to this point.


> I'm not sure this is a bigger issue than what happens
> 'under' the mount points.  If I arbitrarily mount different
> volumes on top of an existing directory between fulls
> and incrementals, what should an incremental tar contain?

If you don't use "fssnap", the mount will hide the the 
content of the mount point and any backup program that
does not work like ufsdump (that directly acccesses the
disk raw device) will fail to archive the related content.

> > Who takes care of the outdated copy of that directory
> > at restore time ?
>
> Gnutar will delete the old one because it won't be listed
> in the contents of the parent directory.

This is the theory. My tests show a different behavior.



> > Users (the experienced and skilled ones) told me
> > that they are uncomfortable with any reference to
> > inodes.
> > 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.
>
> You don't want hardlinks of directories, but hardlinks
> of files are fundmental to unix filesystem semantics.

It was POSIX that did allow hard linked directories....

> > 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.
>
> Archival storage formats like tar/cpio/dump exist for a reason.
> ISO-9660 doesn't represent unix owner/group/permissions/setuid/setgid
> either.  Omit them on a restore and your box won't work.

RR does..


> > So GNU-tar not only ignores the existence of inode-problematic
> > filesystems 
>
> No, it relies on the semantics of stat().

Correct, GNU tar has the same needs as star but gives less 
features in rturn.


> Well, linux wasn't really unix, especially back then. 

It is still not POSIX compliant enough to use Linux as a gauge.


> No - that was the definition from the start.  However,
> atomic rename() was a subsequent addition that allows the
> confusion about the requirement.  Originally, the only
> operations were link() and unlink() and a rename operation
> was two steps that each necessarily affected the link count
> in the inode.  Rename() as a system call was an afterthought
> (a good one, but the implementation did not need to break the
> filesystem design).

Rename() has been added by BSD-4.2 while introducing the 4.2 (FFS/UFS)
file system.


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