On Wed, 2005-06-01 at 02:36 +0400, Nikita Danilov wrote: > Jonathan Briggs writes: > > On Tue, 2005-05-31 at 15:01 -0600, Jonathan Briggs wrote: > > > I should create an example. > > > > > > Wherever I used True Name previously, use OID instead. True Name was > > > simply another term for a unique object identifier. > > > > > > Three files with OIDs of 1001, 1002, and 1003. > > > Object 1001: > > > name: /tmp/A/file1 > > > name: /tmp/A/B/file1 > > > name: /tmp/A/B/C/file1 > > > > > > Object 1002: > > > name: /tmp/A/file2 > > > > > > Object 1003: > > > name: /tmp/A/B/file3 > > > > > > Three query objects (directories) with OIDs of 1, 2, and 3. > > > Object 1: > > > name: /tmp/A > > > name: /tmp/A/B/C/A > > > query: name begins with /tmp/A/ > > > query result cache: B->2, file1->1001, file2->1002 > > > > > > Object 2: > > > name: /tmp/A/B > > > query: name begins with /tmp/A/B/ > > > query result cache: C->3, file1->1001, file3->1003 > > > > > > Object 3: > > > name: /tmp/A/B/C > > > query: name begins with /tmp/A/B/C/ > > > query result cache: A->1, file1->1001 > > > > > > Now there is a A -> B -> C -> A directory loop. But removing > > > name: /tmp/A/B/C/A from Object 1 fixes the loop. Deleting Object 1 also > > > fixes the loop. Deleting any of Object 1, 2 or 3 does not affect any > > > other object, because in this scheme, directory objects do not need to > > > actually exist: they are just queries that return objects with certain > > > names. > > One problem with the above is that directory structure is inconsistent > with lists of names associated with objects. For example, file1 is a > child of /tmp/A/B/C/A, but Object 1001 doesn't list /tmp/A/B/C/A/file1 > among its names.
file1 *appears* to be a child because it is actually returned as the
query result for its name of /tmp/A/file1 because A is a query
for /tmp/A/. If the shell was smart enough to normalize its path by
asking the directory for its name, it would know that /tmp/A/B/C/A
was /tmp/A. But yes, a stupid program could be confused by the
difference between names.
>
> >
> > I forgot to address Nikita's point about reclaiming lost cycles. In
> > this case, let me create Object 4 for /tmp
> > Object 4:
> > name: /tmp
> > query: name begins with /tmp/
> > query result cache: A->1
> >
> > Now, if we delete Object 4, are Objects 1,2,3 lost? I would say not
> > because they still have names. When the shell calls chdir("/tmp") a new
> > query object (directory) must be created dynamically, and Objects
> > 1001,1002,1003 still have their names that start with /tmp and so they
> > immediately appear again. Their names still start with /, so the top
> > level query will still find them and /tmp as well.
>
> Object 4 is "/tmp". Once it was removed what does it _mean_ for, say,
> Object 1003 to have a name "/tmp/A/B/file3"? What is "/tmp" bit there?
> Just a string? If so, and your directories are but queries, what does it
> mean for directory to be removed? How mv /tmp/A /tmp/A1 is implemented?
> By scanning whole file system and updating leaf name-lists?
Well, the name doesn't mean anything. :-) It is just a convenient
metadata for describing where to find the file in a hierarchy, and for
Unix compatibility.
If a directory was removed by a standard rm -rf, it would work as
expected because it would descend the tree removing names (unlink) from
each object it found.
Moving an object with "mv" would change its name. Moving a top-level
directory like /usr would require visiting every object starting
with /usr and doing an edit. A compression scheme could be used where
the most-used top-level directory names were replaced with lookup
tables, then /usr could be renamed just once in the table.
> It seems that what you are proposing is a radical departure from file
> system namespace as we know it. :-) In your scheme all structural
> information is encoded in leaves _only_, and directories just do some
> kind of pattern matching. This is closer to a relational database than
> to the current file-systems where directories are the only source of
> the structural inform
Yes. :-) It is radical, and the idea is taken from databases. I
thought that seemed to be the direction Reiser filesystems were moving.
In this scheme a name is just another bit of metadata and not
first-class important information. The name-query directories would be
there for traditional filesystem users and Unix compatibility. They
would probably be virtual and dynamic, only being created when needed
and only being persistent if assigned meta-data (extra names (links),
non-default permission bits, etc) or for performance reasons (faster to
load from cache than searching every file).
--
Jonathan Briggs <[EMAIL PROTECTED]>
eSoft, Inc.
signature.asc
Description: This is a digitally signed message part
