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

[email protected] wrote:

> > > How is the 64 bit problem with NT to be solved ?
> > > By a giant persistent translation table ? 
> > > The temptation to stretch the rules is substantial for
> > > implementors of innovative fileystems.
> > 
> > The way I did derscribe it with my last mail: POSIX.1-2001 allows basic 
> > cardinal OS types to be wider than sizeof(long). Former Cygwin versions
> > did hash NT file serial numbers to 32 bit and failed (and so did mkisofs
> > with trying to find hard links) and newer ones (since abut a year) just
> > use 64 bits.
>
> 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.

This seems to be an interesting aspect of ZFS on Solaris too.
Let us ask the developers what happens if you create a lot of
files on a ZFS partition :-)

A ZFS partition with more than 32 TB should easily be able to have
more then 4 G inodes. It may be that you will not be able to stat(2)
the files with inode numbers > 4 G in this case if you run a 32 bit
application.


> > Not in case that the filesystem follows POSIX correctly.
> > 
> > Well: I encourage you to send a bug report to the maintainers
> > of the filesystems that behave incorrect.
> > > No bug, but feature. It [ReiserFS] complies to POSIX man rename(2).
> > 
> > So it _does_ update ctime on rename(2)?
> > 
> > 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.

The word "shall" seems to be unambiguous for me....
although some windy people will now tell me that only the 
word "must" denotes a real requirement.


> In reply i was able to point you to a possible disappointment
> of users who might have a hard time picking a single renamed
> file out of a multi-level star backup.

Well if you have a data base with file names for the incrementals,
it should be fairly easy as long as the OS correctly updates ctime
on a rename.

> The reason why i started to participate in this thread was
> to contradict the statement of Les that there was no
> alternative to incremental concepts which rely on single-file
> ctime update on rename.
> Two independent counterexamples have been discussed now :
> - star, which does not need that ctime update if a single, whole
>   filesystem is backuped - and if it is restored as a whole.
> - my own concept which i developed from intrusion detection
>   ideas.

I forgot, how does your method work?


> During the discussion i mistrusted two assumptions :
>
> - The accuracy of ctime of renamed files.
>   This is a practical and widespread problem and there is no
>   hope that POSIX will help us to enforce the assumption in future.
>
> - Persistence of inode and device numbers.
>   This is a theoretical fear. I did not encounter problems yet.
>   Nevertheless i still got no confirmation that the contrary
>   is indeed clearly demanded by POSIX. (Pity.)

Inode numbers should be persistent as long as the implementation is
a decent one.

On an NFS client, the st_dev field may change on a remount. But you 
should not make incremental dumps from a NFS client but rather from the
server.

For local devices, you depend on the way the OS is implemented.
If you depend on Linux, you suffer from the inability of Linux
to have persistent device IDs for something like USB. Note that this
is nust another reason for _not_ trying to backup a logical file tree
that contains sub mounts as Les likes to mandate.

With ufsdump, you will even fail with a single file system because
ufsdump remembers the /dev/* entry for the backup verification (unless
you use the Solaris variant that allows you to overwrite this name).

With star, you have no problems as long as you stay with what star
currently limits you to: one backup == one filesystem. As star 
remembers the mount point for verification, there is no problem is st_dev is not
persistent.

With GNU tar and an attempt to achive a logical file tree that crosses
mount points, you will fail if st_dev is not persistent over the time
of the incremental backups.

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