indexed directories and the File Server

indexed directories and the File Server

[beto]

In <199707110003.UAA24997@cse.psu.edu>
 jmk@plan9.bell-labs.com wrote:

> 	It would be nice if the file server could reuse
> 	drivers from the term/cpu kernel.
>
> After the last filesytem go-round at the beginning of this
> year the drivers became very similar to those of the main kernel.
> I've actually worked out how to make them the same but it's not
> implemented yet. The overall plan would be to make the bootstrap,
> Brazil, Inferno and fileserver drivers all the same, currently
> only the Brazil and our Inferno drivers are.
>
> Of course, none of this helps you at the moment.
>
Well it's always cool to know that things are improving.
Who knows one day Brazil could be released.

indexed directories and the File Server

[Nigel]

Further, making a driver FS/CPU dual compilable is not hard. I didn't do
a very tidy job on the NCR SCSI driver, but it didn't touch much. In
fact, it also compiles for the BeBox which needs to distinguish DMA
space, kernal space, and physical space.

>-----Original Message-----
>From:	jmk@plan9.bell-labs.com [SMTP:jmk@plan9.bell-labs.com]
>Sent:	Friday, July 11, 1997 12:56 AM
>To:	9fans@cse.psu.edu
>Subject:	Re: indexed directories and the File Server
>
>	It would be nice if the file server could reuse
>	drivers from the term/cpu kernel.
>
>After the last filesytem go-round at the beginning of this
>year the drivers became very similar to those of the main kernel.
>I've actually worked out how to make them the same but it's not
>implemented yet. The overall plan would be to make the bootstrap,
>Brazil, Inferno and fileserver drivers all the same, currently
>only the Brazil and our Inferno drivers are.
>
>Of course, none of this helps you at the moment.

indexed directories and the File Server

[jmk]

	It would be nice if the file server could reuse
	drivers from the term/cpu kernel.

After the last filesytem go-round at the beginning of this
year the drivers became very similar to those of the main kernel.
I've actually worked out how to make them the same but it's not
implemented yet. The overall plan would be to make the bootstrap,
Brazil, Inferno and fileserver drivers all the same, currently
only the Brazil and our Inferno drivers are.

Of course, none of this helps you at the moment.

indexed directories and the File Server

[beto]

In <199707102115.QAA06074@ns.dbSystems.com>
 "G. David Butler" <gdb@dbSystems.com> wrote:

> I would also like to start a concurrent discussion about the File
> Server.  When I first started with Plan9, I thought having two
> different kernels was weird.  Now I think the idea is sound since
> they have such different roles.

I also like the idea of different kernels, there are so many oportunities
for optimizations. The main problem is how to keep drivers in
both places in sync. It would be nice if the file server could reuse
drivers from the term/cpu kernel. For example,our bootstrap
program (9b.n3) reuses most of the drivers from 9. The same should be
possible with fs.

>So the next question, do we put the
> above functionality into kfs and make the cpu kernel and kfs able
> to handle file services efficiently or do we keep the current
> File Server?  (If we keep the File Server, we need to add an il
> version of a port 23 server to provide access to the console.  In
> fact, that is a good idea for the cpu server too.  TCP is missing
> in the File Server, as it should.)
>
I think the fact that the file system does not talk TCP/23 in on
purpose, you don't want people connection to it in that way.
Have a look to consolefs.

A better replacement for kfs as a local file system is to transform
it into a driver (devnvfs, this name is taken from inferno). I like this
idea because then the same process could copy the data directly
from the cache into user land. I've started doing something like this a
couple of months ago, but haven't done much since.

I need longer lunch breaks :-).

indexed directories and the File Server

[G.David]

On to the next project.

One of the big things I've always hated about *NIX was the exponential
search time directories.  I am going to do something about it in Plan9.
I have some Btree routines I wrote in '89 that would work very well here.
They are very simple and allow only search, insert and delete.  No
first, last, next and previous.  An update (rename) would be a delete
followed by an insert.

I see two ways to implement this.  First, change the allocation method
for directores from an "array" to a Btree.  The first direct block
points to the root block of the tree.  The directory blocks then
could have a structure like this:

struct IndexEntry {
  struct DirEntry
  long RightNodeBlockPointer
}

struct IndexBlock {
  struct IndexEntry[number that fills page]
  long LeftNodeBlockPointer
  int number of used entries
}


The other way would be to build an index on the directory entries and
leave the current directory structure alone.  A question is where to
store the blocks for the index?  We could use the first direct block
as above as a pointer to the root of the Btree and leave the other
5 direct, 1 indirect and 1 double-indirect for the directory as usual.
The index block could look like (dir blocks would not change):

struct IndexEntry {
  long DirSlotNumber <The key is name @ dirslotnumber not dirslotnumber>
  long RightNodeBlockPointer
}

struct IndexBlock {
  long number of used entries
  long LeftNodeBlockPointer
  struct IndexEntry[number that fills page]
}


I would also like to start a concurrent discussion about the File
Server.  When I first started with Plan9, I thought having two
different kernels was weird.  Now I think the idea is sound since
they have such different roles.  So the next question, do we put the
above functionality into kfs and make the cpu kernel and kfs able
to handle file services efficiently or do we keep the current
File Server?  (If we keep the File Server, we need to add an il
version of a port 23 server to provide access to the console.  In
fact, that is a good idea for the cpu server too.  TCP is missing
in the File Server, as it should.)

Any comments?  :-)

David Butler
gdb@dbSystems.com