Re: File as a directory - VFS Changes

[Jonathan Briggs <jbriggs@esoft.com>]

[-- Attachment #1: Type: text/plain, Size: 1772 bytes --]

On Tue, 2005-05-31 at 12:30 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 31 May 2005 08:04:42 PDT, Hans Reiser said:
> 
> > >Cycle may consists of more graph nodes than fits into memory. 
> > >
> > There are pathname length restrictions already in the kernel that should
> > prevent that, yes?
> 
> The problem is that although a *single* pathname can't be longer than some
> length, you can still create a cycle.  Consider for instance a pathname restriction
> of 1024 chars.  Filenames A, B, and C are all 400 characters long.  A points at B,
> B points at C - and C points back to A.
> 
> Also, although the set of inodes *in the cycle* fits in memory, the set of
> inodes *in the entire graph* that has to be searched to verify the presence of
> a cycle may not (in general, you have to be ready to examine *all* the inodes
> unless you can do some pruning (unallocated, provably un-cycleable, and so
> on)).  THis is the sort of thing that you can afford to do in userspace during
> an fsck, but certainly can't do in the kernel on every syscall that might
> create a cycle...

You can avoid cycles by redefining the problem.

Every file or "data object" has one single True Name which is their
inode or OID.  Each data object then has one or more "names" as
properties.  Names are either single strings with slash separators for
directories, or each directory element is a unique object in an object
list.  Directories then become queries that return the set of objects
holding that directory name.  The query results are of course cached and
updated whenever a name property changes.

Now there are no cycles, although a naive Unix "find" program could get
stuck in a loop.
-- 
Jonathan Briggs <jbriggs@esoft.com>
eSoft, Inc.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]