On Tue, 2005-05-31 at 12:30 -0400, [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> eSoft, Inc.
signature.asc
Description: This is a digitally signed message part
