[9front] Design principles for Plan 9 file systems?

[9front] Design principles for Plan 9 file systems?

[Joël Franusic]

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

I'm studying the designs used by user level file servers in Plan 9 (acme, factotum, plumb, etc) and would love to talk to people who have opinions about what good "API" design looks like for a Plan 9 file system. For example: "Which file systems do you like?", "Which are worth studying?", "What are some mistakes to avoid?", etc

Ultimately, I'd like to come up with a set of guidelines or principles to follow when writing a file server such that a Plan 9 veteran could mount the provided file system and quickly understand how it works.

For references, here are the "APIs" that I've collected so far, based on what I've found in various research papers:

ACME

/mnt/acme/index

/mnt/acme/new

/mnt/acme/$n/addr

/mnt/acme/$n/body

/mnt/acme/$n/ctl

/mnt/acme/$n/data

/mnt/acme/$n/event

/mnt/acme/$n/tag


Factotum

/mnt/factotum/confirm

/mnt/factotum/ctl

/mnt/factotum/log

/mnt/factotum/needkey

/mnt/factotum/proto

/mnt/factotum/rpc


Plumb

/mnt/plumb/rules

/mnt/plumb/send

/mnt/plumb/edit

/mnt/plumb/web

/mnt/plumb/image

/mnt/plumb/newmail

/mnt/plumb/…


All of my notes are being kept in a Google Doc for now, which is available here: https://docs.google.com/document/d/1g-GIjJRoa7yfOuSjxYG-owBwVh1QaMzOa5i19vVtxUM/edit?usp=sharing

-- 
  Joël Franusic
  joel@franusic.com

[-- Attachment #2: Type: text/html, Size: 15634 bytes --]

[9front] Re: Design principles for Plan 9 file systems?

[Anthony Martin]

Joël Franusic <joel@franusic.com> once said:
> Ultimately, I'd like to come up with a set of guidelines or principles
> to follow when writing a file server such that a Plan 9 veteran could
> mount the provided file system and quickly understand how it works.

The 9P protocol gives you a uniform API for interacting with a
resource: open, read, write, close. How you represent a specific
resource depends on what the resource is or does. There are
some clear patterns that most file systems use to model their
resources:

- single control file

- multiple control files

- control file and data file

- filter

- multiplexer

- protocol converter

It's not a coincidence that all of them have roots in signal
processing and telecom work. Bell Labs was part of the
phone company after all.

Study Sandy Fraser's work if you seek enlightenment.

As for what goes into the control files, it's usually simple
messages akin to writing registers on a device or setting
up a call on a switch. Deviation from this is unusual.

Cheers,
  Anthony

Re: [9front] Design principles for Plan 9 file systems?

[Ori Bernstein]

This is a good starting point:

https://doc.cat-v.org/plan_9/misc/ubiquitous_fileserver/ubiquitous_fileserver.pdf

On Wed, 26 Jun 2024 00:50:46 -0700
Joël Franusic <joel@franusic.com> wrote:

> I'm studying the designs used by user level file servers in Plan 9 (acme, factotum, plumb, etc) and would love to talk to people who have opinions about what good "API" design looks like for a Plan 9 file system. For example: "Which file systems do you like?", "Which are worth studying?", "What are some mistakes to avoid?", etc
> 
> Ultimately, I'd like to come up with a set of guidelines or principles to follow when writing a file server such that a Plan 9 veteran could mount the provided file system and quickly understand how it works.
> 
> For references, here are the "APIs" that I've collected so far, based on what I've found in various research papers:
> 
> ACME
> 
> /mnt/acme/index
> 
> /mnt/acme/new
> 
> /mnt/acme/$n/addr
> 
> /mnt/acme/$n/body
> 
> /mnt/acme/$n/ctl
> 
> /mnt/acme/$n/data
> 
> /mnt/acme/$n/event
> 
> /mnt/acme/$n/tag
> 
> 
> Factotum
> 
> /mnt/factotum/confirm
> 
> /mnt/factotum/ctl
> 
> /mnt/factotum/log
> 
> /mnt/factotum/needkey
> 
> /mnt/factotum/proto
> 
> /mnt/factotum/rpc
> 
> 
> Plumb
> 
> /mnt/plumb/rules
> 
> /mnt/plumb/send
> 
> /mnt/plumb/edit
> 
> /mnt/plumb/web
> 
> /mnt/plumb/image
> 
> /mnt/plumb/newmail
> 
> /mnt/plumb/…
> 
> 
> All of my notes are being kept in a Google Doc for now, which is available here: https://docs.google.com/document/d/1g-GIjJRoa7yfOuSjxYG-owBwVh1QaMzOa5i19vVtxUM/edit?usp=sharing
> 
> -- 
>   Joël Franusic
>   joel@franusic.com


-- 
Ori Bernstein <ori@eigenstate.org>

Re: [9front] Design principles for Plan 9 file systems?

[Joël Franusic]

Oh this is perfect. I'm not sure how I missed this paper. I'm going to read it now. Thanks so much!

-- 
  Joël Franusic
  joel@franusic.com

On Wed, Jun 26, 2024, at 15:14, Ori Bernstein wrote:
> This is a good starting point:
>
> https://doc.cat-v.org/plan_9/misc/ubiquitous_fileserver/ubiquitous_fileserver.pdf
>
> On Wed, 26 Jun 2024 00:50:46 -0700
> Joël Franusic <joel@franusic.com> wrote:
>
>> I'm studying the designs used by user level file servers in Plan 9 (acme, factotum, plumb, etc) and would love to talk to people who have opinions about what good "API" design looks like for a Plan 9 file system. For example: "Which file systems do you like?", "Which are worth studying?", "What are some mistakes to avoid?", etc
>> 
>> Ultimately, I'd like to come up with a set of guidelines or principles to follow when writing a file server such that a Plan 9 veteran could mount the provided file system and quickly understand how it works.
>> 
>> For references, here are the "APIs" that I've collected so far, based on what I've found in various research papers:
>> 
>> ACME
>> 
>> /mnt/acme/index
>> 
>> /mnt/acme/new
>> 
>> /mnt/acme/$n/addr
>> 
>> /mnt/acme/$n/body
>> 
>> /mnt/acme/$n/ctl
>> 
>> /mnt/acme/$n/data
>> 
>> /mnt/acme/$n/event
>> 
>> /mnt/acme/$n/tag
>> 
>> 
>> Factotum
>> 
>> /mnt/factotum/confirm
>> 
>> /mnt/factotum/ctl
>> 
>> /mnt/factotum/log
>> 
>> /mnt/factotum/needkey
>> 
>> /mnt/factotum/proto
>> 
>> /mnt/factotum/rpc
>> 
>> 
>> Plumb
>> 
>> /mnt/plumb/rules
>> 
>> /mnt/plumb/send
>> 
>> /mnt/plumb/edit
>> 
>> /mnt/plumb/web
>> 
>> /mnt/plumb/image
>> 
>> /mnt/plumb/newmail
>> 
>> /mnt/plumb/…
>> 
>> 
>> All of my notes are being kept in a Google Doc for now, which is available here: https://docs.google.com/document/d/1g-GIjJRoa7yfOuSjxYG-owBwVh1QaMzOa5i19vVtxUM/edit?usp=sharing
>> 
>> -- 
>>   Joël Franusic
>>   joel@franusic.com
>
>
> -- 
> Ori Bernstein <ori@eigenstate.org>