[KLUG Members] New advances in filesystems.

Adam Tauno Williams members@kalamazoolinux.org
Tue, 15 Jul 2003 17:00:31 -0400


> First of all, did everyone see the Monday USA Today Money-section cover
> story on Linux beating M$ in Munich? It takes up all of page 2. :-D

I saw the story linked from LWN.  Very cool!  And people actually read USA
today, it is pretty hard to beat this as far as good press goes.  

Poor Mr. Mundie.  At least he is getting lots of frequent flyer miles. :)
 
> I read the PDF, too. It strikes me as a very lightweight and rather
> underthought paper on some of the more fascinating ideas out there on
> filesystems and traditional UNIX problems.
> I remember reading the following joke a year or two ago:
> Under Unix, everything is a file.
> Under Linux, everything is a filesystem.
> and wondering what the joke was. It seemed brilliant to me. Apparently,
> it seemed that way to the makers of Plan 9, as well, because that's just
> what they did. Al Viro, the demigod of Linux VFS, is a participant on
> Plan 9 mailing lists.

I love the VFS,  I just think it can be taken to an illogical extreme.

> > Every possible TCP/UDP port as a file?  I thought /dev was ugly enough
> > already.
> Only when you let some moron precreate every file. Linux's devfs, though
> under fire from a number of camps for a number of reasons (right down to
> the author's coding style), makes /dev look positively pretty. Forget
> lspci, unless you're looking for some really obscure piece of hardware.

Currently lspci just cats /proc/pci with some dressing.  Expressing things as
files is nice, sort of an easy-way-to-make-an-API.  But management through all
these files doesn't really follow as a great idea, IMHO.

> `ls /dev/$something` is enough. Look at the following:
> http://kt.zork.net/kernel-traffic/kt20030428_214.html#10
> http://kt.zork.net/kernel-traffic/kt20030309_208.html#4
> http://kt.zork.net/kernel-traffic/kt20030113_200.html#2
> http://kt.zork.net/kernel-traffic/kt20021014_188.html#7
> http://kt.zork.net/kernel-traffic/kt20020923_185.html#6
> for some more information about the attempts to hammer devfs or udev
> into shape.

devfs is good,  the paper didn't mention devfs (or I missed it).

> LDAP is just another transport protocol, not unlike HTTP. 

No.  LDAP is a transport protocol and a data model, as well as a structure for
organizations to cooperate and share schema information.  Allocation via IANA; I
can trace a schema definition back to it's author, etc...  What E-mail client
that supports LDAP (and how many don't) doesn't use the inetOrgPerson schema?  I
haven't found one.  They may extend it (evolutionPerson, officePerson, etc...)
but they can all interoperate on basic information.

> Exporting data  over it does not extend Linux in the slightest. 
> These new ideas (9P,
> devfs, udev) are all about building new capabilities into Linux itself
> -- and then, if you like, you can export their data/permissions over
> LDAP/Kerberos (or in XML -- which is another transport people are trying
> to press into foreign service).

Sure, but I'm not convinced it will work out so nicely in the real world.  How
does a file handle itself expiring, etc... Alot of this seems to be just
re-inventing the DSA, but as a filesystem,  when I'm not sure anyone wants such
a thing.

> Frankly, Adam, your presentation on Kerberos V was fascinating and
> frightening. Running a Windows network at CARES, I was interested to
> learn more of the model underneath it, which you explained really well.
> But your description of the layers and config files required to
> implement KV convinced me I would never install it at home. You said you
> wanted to get rid of all the tiny files that govern sign on!

A stock Kerberos client needs only one file, /etc/krb5.conf, aside from the
keytab.  Actually you can do without that file, using DNS SRV (which M$-ADS
does).  But that usually snows people (not certain why), so I avoid talking to
much about it (although it is mentioned).  Once basic Kerberos works someone can
"graduate" upwards if they are interested in doing so.

> Well, this is how they're going to do it.

We'll see.  I'm a bit of a skeptic.  Although I'm certain some parts of these
concepts will be adopted.