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

[email protected] wrote:

> > If you believe that there are Linux 6 billion Linux users....
>
> Not yet, not yet.
> But there are 6 billion who do not reach your standards
> of reasonability.

???

> > A simple experiment in mind would allow you to prove this:
>
> I would rather like to be able to point to an
> accepted standard which clearly prescribes it.

The problem with POSIX is that many things are obvious to several people
but not to everyone. In such a case, you would need to send a defect report.

Let me make an example: uid_t is a _signed_ int but it is not allowed
to use negative uid's. This fact is not mentioned in the doc for sys/types.h.


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


> > > Let me assume a three level star backup of a complete filesystem,
> > > where the data content of a file was recorded at level=0 and the
> > > most recent name change was recorded at level=2 :
> > >   How do i retrieve my single file under its _recent_ name without
> > >   doing a full restore (which might overextend my disk) ?
> > 
> > No backup system that I am aware of allows you to retrieve a file
> > if you don't know the name that was in use for the time you like
> > to restore.
>
> I know the recent name.
> But for that name there is only meta data and no body.
> The body is stored on a lower level under the old name.

Not in case that the filesystem follows POSIX correctly.

If the fs does not follow POSIX, then there is even no complete meta data
because you then only have name/ino.

> In my qabove question i assume that only meta data
> is recorded because neither mtime nor ctime of the
> file have been changed on rename. Only the parent
> directory's timestamps have been updated. 
> May it be that the whole directory was renamed or
> may the filesystem exploit the tolerance of POSIX'
> specification of rename(2). For what cause ever:
>
> There are situations where the current name of a
> file is one level and the data body is on an older
> level which cannot know about the current name.

So you found a problem that I should document:

star is able to deal with a rename(2) that does not update
the ctime of the renamed file but in this case the file is not
in the backup and this fact may cause problems in case you like
to restore a single file.

Well: I encourage you to send a bug report to the maintainers
of the filesystems that behave incorrect.


> >> They are just cautious not to open any encapsulation
> >> without need.
> > 
> > ??? 
>
> The encapsulation (as OO programming term) to assume
> a particular implememtation structure of the tree
> filesystem model. Today i assume something and tomorrow
> i am in trouble because somebody broke the assumption.
> It is far more easy to beat off the boss' attempt to
> introduce a non-tree filesystem than to tell him about
> the need for inodes and hearsaid POSIX rules.

???
Make an example.... and please note that anybody who implements
a filesystem that does not sollow POSIX semantics creates a bug.

Note that the POSIX FS semantics are definitely written in a
way that makes the simplest set assupmtions that are possible 
just to give the implementors of a filesystem the most possible
freedom. This is why GNU find is broken because it by default
makes assumptions that are non POSIX.


> > If ReiserFS is broken, then people should make bug reports.
>
> No bug, but feature. It 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.


> >> Les and i were talking about the ctime of the
> > 
> > Irrelevent for star.
>
> But not for several others.
> (Sorry for misusing the starusers list.
>  But such pitfall discussions are on topic, and if
>  it's only for making clear that star does not fall 
>  into the pit.)

I am no longer sure what traget issue you have with this
discussion...


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