[Gnu-arch-users] hurd foo

[Thomas Lord]

Ludovic:

> The Hurd is designed from the ground up to have filesystems
> implemented in user-space.  In fact, it considers filesystems as
> "normal applications", which they are, indeed.  The number of
> libraries/programs that implement their own VFS actually proves that
> filesystems ought to be treated as applications.


The claim that filesystems are a "normal application" is becoming
more true in two senses:

  1) Disk Economics

     Expect disks to have hella beefy controllers, Tb-capacity
     storage, a modest but impressive amount of NV ram, and 
     more than enough low-latency bandwdith between host and 
     disk.   Expect them also to have lousy latency and so-so
     bandwidth between controller and physical media (other than
     NV ram).   Expect all of this by default -- these are the
     "couple hundred dollar disks" you buy as a commodity from
     whomever has the best price that month (among a small number
     of reliable sellers).

     A lot of low-level file system functionality thus gets pushed
     to the controller.   Expect to see all that code in yr kernel
     that obsesses over disk geometry to finally die.   Expect
     that shared memory and `mmap'-ed files give plenty good 
     performance from user-space processes to the (then) raw 
     disk.  (Yes, geometry abstraction is already happening but
     what's on the preview channel is that it's absolutely 
     clinched.) [1]

  2) Plan 9 is Right

     Uniform access methods and a uniform namespace simplify
     things at all levels. [2]


> OTOH, Linux considers file systems as integral parts of the kernel,
part
> of the trusted computing base (TCB).  This typically precludes the
> implementation of filesystems such as tar+gz, or other complex file
> systems that need a lot of code and may not reasonably be audited the
> way regular kernel code is.

Semantics matter.  By the time you are disguising a tar+gz as a file
system you have so many semantic issues (e.g., atime) that, well,
performance is the least of yr concerns.  The only bad thing to say
about the linux kernel approach is that, in the next decade, it
pretty much has to get a lot smaller and simpler (as code migrates
from kernel to disk controller).

> Therefore, FUSE had to work around this assumption (filesystems being
> in-kernel) by implementing in-kernel glue code that would just forward
> I/O syscalls to some user-level application.  Compared to the Hurd's
> design, it looks quite hackish.

There's so many things wrong with this assesment I barely want to 
touch it.

Yes, Hurd reached for a platonic ideal and good for them but
it wasn't a very practical approach.   Meanwhile, please estimate
what it takes to port a file system written to the hurd interfaces
to Linux.


> You might want to look at:
> http://www.gnu.org/software/hurd/hurd-paper.html .

You might also want to look at BSD union directories.

> Note that Plan 9 has a similar approach to file systems.

Plan 9 is underappreciated for its politically and technically
significant approach to namespace management and for the fact
of its simplicity, relative to popular systems, in relation
to the amount of functionality delivered.   (The Hurd does
not share those virtues.)

-t