Hi,
> 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.
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.
> > http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html
> > "3.175 File Serial Number
> > A per-file system unique identifier for a file."
>
> A pair of st_ino/st_dev uniquely identifies a file for the lifetime
> of the file.
"Lifetime", _such_ a word would soothe my concerns.
Do me the favor and tell me where this is written.
A complete POSIX document identifier or the exact
quote would suffice. I would try to learn the rest
alone.
> The man page of star is sufficient. As long as people believe that
> GNU tar is a useful backup system, I see no reason to extend the
> warnings.
Usually you strive for higher standards.
> > 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.
That is what my star experiments in august 2005 suggest
and that is what you confirmed me a few days ago :
>> ( Fri, 07 Oct 2005 13:20:10 +0200 , 434659EA.nail221DZRUC@burner )
>> > me:
>> > Is my understanding of star correct that in this case
>> > it only records the directory with its pairs of names and inodes
>> > but not the files' content (which is unchanged) ?
>> > That at restore time, the content already got restored by
>> > a previous level and then gets attached to these newer
>> > directory entries ?
>>
>> you:
>> Correct.
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.
I do not critisize this, notabene, because i still
think it is very elegant and rewarding in the full
backup and full restore scenario.
I just offer some resistence against your flat
statement that always recording meta-data and file
data on the same volume was "extremely dumb".
>> 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.
> If ReiserFS is broken, then people should make bug reports.
No bug, but feature. It complies to POSIX man rename(2).
>> Urm. I read "of the parent directory of each file".
>
> Correct! This is what star meeds ;-)
That's why its method is elegant in my eyes.
>> 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.)
> Be careful, the [incremental backup] algorithm is not
> trivial and it took me nearly half a
> year in order to get it 100% correct.
I had my main research between december 2002 and march
2004. But now i revisit the topic for speed and bandwidth
reasons. Currently disk capacities seem to grow faster
than the performance of RAM and CPUs.
Have a nice day :)
Thomas
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.