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

[email protected] wrote:

> Hi,
>
> > > Yes. But if i would strive for NT filesystem access from
> > > a 32-bit OS where ino_t happens to be 32-bit ...
> > > ... you see the temptation to stretch POSIX to the max
> > > in order to achieve a bearable solution ?
> > 
> > The 32 bit ino_t relation for a 32 bit OS is UNIX specific but not 
> > required by POSIX.1-2001 or later.
>
> I understand that a _new_ 32-bit operating system version is
> not bound to sizeof(ino_t)==4.
> But any _old_ instance of a 32-bit Linux which is running
> in real life will be unable to accomodate with a filesystem
> that uses 64-bit file serial numbers.
> So there will be a certain pressure to do such a 64-to-32
> translation which according to Dirichlet's drawer principle
> (aka pigeon hole) can hardly be collision-free by nature
> but only by expensive implementation add-ons. And only if there
> are less than 4 billion inodes in the filesystem.

I just checked that sizeof (ino_t) is 8 on Solaris in case you
compile large file aware. It seems that I have been in the wrong
section of stat.h before.

> > > > Note that POSIX _requires_ ctime to be updated on a rename.
> > >
> > > No, it doesn't.
> > 
> > If definitely _requires_ ctime to be updated on a rename.
> > 
> > Upon successful completion, rename() shall mark for update the st_ctime and 
> > st_mtime fields of the parent directory of each file.
>
> But that is about the parent directory.

OK.


> Les, GNU-tar and i refered to the renamed file's own
> timestamps. These are mentioned too in the same man page
> as your above quote. And their ctime is allowed to change
> or to stay unaltered at the implementor's discretion.

The problem with GNU tar incrementals is that GNU tar fails the
same way as star fails in case that inode numbers of renamed directories
are not persistent.

> It usually relies on the parent directory timestamp
> rule as of POSIX rename(). If the timestamps of a file
> are old but timestamps of a directory above are new,
> then the file's content is checked against a recorded
> checksum.
> Reasons to avoid the checksum test and to assume the file
> as young enough are : young timestamp,
> non-existence in recorded tree model, changed type,
> changed size.
> No file is assumed old unless all its parent directories
> are old or unless its checksum has been verified. The
> parent directory assumption may be disabled if the user
> is very mistrusting.

This forces you to have a persistent and probably big checksum
database.


> Whenever the user encounters a system with unstable
> device and inode numbers, the effect will become obvious
> by much too fat incremental backups.

It does with most incremental backup methods.



> That's why i am astonished that you offer partial incrementals
> with star, although you know that it opens the door for
> gaps in the backup's data content. This pierces the
> solid consistency of star's approach, which is quite
> fool-proof elsewise.

As the backup includes a tag that defines the backup full or partial,
I see no real problem. People should know that partial backups
may have problems and they could easily check if they are talking about
a partial backup.

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