On Wed, 10 May 2000 04:15:33 Brent Fulgham wrote:
> On Wed, May 10, 2000 at 01:33:11AM +0200, Marcus Brinkmann wrote:
> > Hi,
> >
> > maybe my ramblings will be useful for other inodeless fs implementations
> > later.
> >
> > 3. Making up inode numbers on the way:
> > Simply start with 1 and go up for every new file cached. This could be
> > called "virtual inodes". The problem is that there is per se no efficient
way
> > to regain the virtual inode numbers from the file information, when
looking it
> > up (The answer to the question: Do we have the file "foobar" in the
cache?).
> > So, this violates the meaningfulness of the cache_id, but, as it turns
out,
> > in a repairable way.
> >
>
> I know how much everyone seems to hate C++ around here, but the Map template
> provides a fairly elegant solution to this problem. It would be very simple
> to store the "virtual inode" value in a Map of:
>
> Map[char* file-name] -> virtual_inode
>
> Since that construct is not available, perhaps a tree structure of some
kind,
> arranged in the lexicographic ordering of the file names (including paths).
> This insures a unique key for each file, but perhaps there will be speed
> issues.
Uh, we have such a thing like map. It is called a hash :=)
This is exactly what i think is needed to repair the meaningfulness. A
hash from
directory entry location (not filenames) to virtual inode numbers.
> > It turns out that a filesystem with simple data structures can be more
> > complicated to implement. We learn that adding a bit complexity to the
data
> > structures (like inodes) can lead to more efficient and easier to
implement
> > operations on the data. ;)
>
> A very interesting observation (counterintuitive, too!). Just goes to
> show that one can take the KISS (Keep It Simple, Stupid) principal can
> be taken too far. :-)
Well, certainly it doesn't mix with the rich unix semantics of files
(consider that you
can for example rename an opened file and expect it to work).
FAT is a very simple fs, with little support for anything. It only
speaks good of unix and the Hurd in particular
that we can embedd its simplicity in the richer POSIX semantics.
Thanks,
Marcus
