
Linus Torvalds on userspace filesystems - sasvari
http://www.spinics.net/lists/linux-fsdevel/msg46078.html
======
barrkel
An approach for this kind of problem: suppose you have a very simple language
composed of simple, verifiable instructions, like: block read, block write,
read-offset, write-offset, simple arithmetic, simple branching; you could
compose programs for various file-system operations and pass them over to the
kernel for execution en masse, rather than needing a chatty interface.

This basic idea is something I've applied to a file format that stored
objects, but where the costs of serializing and deserializing a whole object
graph was prohibitive for a request/response round-trip. For any given object
path, foo.bar[3].baz, a "program" could be compiled that could be interpreted
over the file contents and the answer retrieved. All object paths were
available for compilation ahead of time (it was a custom language, long
story), so this approach could be far more efficient than any serialization
story.

~~~
pjscott
That reminds me of Singularity OS, an experimental OS from Microsoft Research,
which has no distinction between kernel and user space, thanks to writing
everything in a variant of .NET bytecode.

<http://en.wikipedia.org/wiki/Singularity_(operating_system)>

~~~
barrkel
There have been Java OSes too, with the idea that verifiable bytecode does
away with the need for "expensive" memory protection etc. Running everything
in one memory space is error-prone, but it's the default way of the monolithic
kernel. Having services delegated out to processes with separate memory spaces
is architecturally more stable; a single bug in an obscure driver in a less
actively maintained corner of the kernel shouldn't lead to a system-wide
vulnerability. The approach I mention preserves the ability to keep things
separate (with appropriate controls and verification at the boundary); the
Singularity / Java OS approach seems rather different.

Snoracle says JavaOS itself is obsolete, FWIW.

~~~
btilly
Yet another variant on the idea was the AS 400. It had no memory protection
and didn't need it, since there was no way to address anything that you
weren't supposed to.

Given the impressive stability and security record of the AS 400, they had a
point.

~~~
barrkel
Yes, when you have typed pointers at the hardware level, it can be even better
than page protection.

------
larrik
"That's like saying you should do a microkernel - it may sound nice on paper,
but it's a damn stupid idea for people who care more about some idea than they
care about reality."

He just had to sneak in a dig at Tanenbaum.

~~~
shubber
And, intended or not, at Stallman

~~~
sp332
GNU HURD was hamstrung mainly by politics, not so much by technical issues.
There was a ton of code written, but it kept getting ripped up and thrown out
because someone didn't like it.

~~~
ww520
That sounds like juicy story. Who didn't like it and threw away the code?

~~~
sp332
Note that I'm not claiming that some competent people could fix HURD right now
if the political environment were better. It's more that the politics moved
the project into the least tenable position. I don't know if there's a
complete history somewhere, but just some things I managed to piece together
from Wikipedia articles:

Berkeley wouldn't cooperate with development on the 4.4BSD-Lite modified
kernel, so in 1987 HURD decided to go with the Mach microkernel. But then they
waited 3 years for licensing issues to clear up before investing any real
effort into it. CMU stopped work on Mach in 1994, so HURD switched to Utah
Mach. Utah stopped working on it in 1996. GNU kept working on that one under
the name GNU Mach. And then (from Wikipedia): "In 2002, Roland McGrath
branched the OSKit-Mach branch from GNU Mach 1.2, intending to replace all the
device drivers and some of the hardware support with code from OSKit. After
the release of GNU Mach 1.3, this branch was intended to become the GNU Mach
2.0 main line; however, as of 2006, OSKit-Mach is not being developed.

As of 2007, development continues on the GNU Mach 1.x branch, and is working
towards a 1.4 release."

In 2004, an effort was started to move to a more "modern" microkernel. L4 was
the first and it died almost immediately. Work started toward the Coyotos
microkernel, but between 2007 and 2009, focus shifted to Viengoos. But then
"As of 2011, development on Viengoos is paused due to Walfield lacking time to
work on it. In the meantime, others have continued working on the Mach variant
of Hurd."

------
leif
I don't care what he says, I'm _still_ waiting for an inclusion of some kind
of union mount functionality in mainline. I don't need anything fancy, just
one ro dir and one rw dir. If he can't even get me that in-kernel, I'll stick
with unionfs in fuse, thank you very much.

Don't tell me about aufs, UnionMount, or overlayfs: aufs isn't up to date
because it's not mainlined (for no good reason I can find), and UnionMount and
overlayfs are too far out of mainline and too much in development to find
reasonable packages.

Linus: when you can back up your claims with working code, I'll start
listening. ;-)

~~~
ComputerGuru
Hey, question: What's a convincing use case for a union filesystem?

Also, what I don't think union filesystems are a valid argument. They're not
_real_ filesystems in the way NTFS/FAT/extfs/reiserfs or whatever are —
there's a lot less work to be done, and I could see the falling under the
"toy" category that Linus was talking about...

~~~
leif
squashfs plus unionmount

commonly used for livecds, I compress /usr, saves me about 5GB and some I/O
and therefore some battery

------
gyom
I'm beginning to suspect that people report cases of Linus insulting people
regardless of whether the discussion was interesting or not.

Linus insults someone on a forum -> first page on HN !!

Just a thought.

~~~
dkarl
Yes, if the discussion has some fascinating relevance for the general HN
readership, I can't figure it out. Linus doesn't come off very well, trying to
settle a discussion with common sense and sarcasm while the other people on
the thread use facts and examples to paint a more complicated picture.

 _People who think that userspace filesystems are realistic for anything but
toys are just misguided._

I use sshfs all the time. Much of the software I use every day only needs to
meet "toy" standards to be useful to me. What is Linus on about here?

~~~
icebraining
Yes, but would you rely on it as the filesystem for a public server?

His point isn't that userspace filesystems are useless, but they are much
slower, so the existence of a Fuse filesystem is not an argument for not
including a kernel space filesystem in the kernel.

------
andrewcooke
this reply is a bit more sane - <http://www.spinics.net/lists/linux-
fsdevel/msg46080.html>

glad i don't work with torvlads.

------
pragmatic
Is there a website or book with the collected ideas/opinions of Linus and the
design of linux?

"that's like saying you should do a microkernel - it may sound nice on paper,
but it's a damn stupid idea for people who care more about some idea than they
care about reality."

So I look up this microkernel thing and find this old debate:
<http://www.dina.dk/~abraham/Linus_vs_Tanenbaum.html>

It would be great to have a resource that explains the what and the why behind
the linux architecture. Also arguments, errr I mean debates, between high
caliber smart people would be cool.

There is a book "Just for Fun: The Story of an Accidental Revolutionary" that
I ordered, but I have a feeling it doesn't go into the technical depth I would
like. I could be wrong, just ordered it, will find out.

------
walexander
Anecdotally, a project I worked on involved evaluating some encrypted file
systems on linux and encFS (on FUSE) was at an order of magnitude worse
performance than kernel solutions.

Not to say it could never happen, but the tradeoff on performance is just no
where near worth it right now.

~~~
marshray
I'd suspected performance might not be the primary purpose when I came across
the Python packages for implementing filesystems.

Still, it seems like a lot of the interesting filesystem ideas have to do with
non-root users authenticating to something else over some network connection.
This type of thing is simply a more natural fit for user space.

Keeping the high-level stateful protocol stuff out of the kernel is usually a
good idea except when performance is all that matters (i.e. there will be
full-time developers tuning it and cleaning up the inevitable security and
crash bugs).

------
michael_dorfman
It's a bit amusing to see Linus, all these years after his famous dispute with
Tanenbaum, still fighting microkernels. Personally, I think that the Minix
source code shows that microkernels are quite viable, and that Linus's disdain
is misguided.

~~~
hristov
How does the Minix source code prove this? Minix has existed long before Linux
and yet Linux made enormous gains in popularity while Minix is still minor and
very rarely used.

Has the Minix kernel shown significant performance results? (I am not being
sarcastic btw, I am honestly asking.)

I know OSX uses something like a micro-kernel and it is a perfectly fine
desktop OS, but performance suffers once you get to thousands of threads.

~~~
msbarnett
I don't think XNU is a microkernel in any real sense. Certainly not in the
sense that the Minix kernel is or was.

The filesystem, device drivers, IPC, network stack, etc is all in kernel
space. It's true that it's built around the Mach microkernel, but like most
systems that built around it, Mach is just a core layer in the kernel onion,
rather than a microkernel in and of itself with the other major components
implemented as user-space servers.

~~~
demallien
Ummm, IPC pretty much has to be in the kernel, by definition...

~~~
msbarnett
_A_ low-level IPC mechanism needs to exist in the microkernel. Higher-level
IPC mechanisms that applications will actually care about and use certainly
don't need to; see, for example, pipes in Minix.

------
16s
If you've ever implemented real-world code that solves a problem you'll find
that there are some people (mostly who have not implemented much practical
code but read a lot about it) who want to tell you how you _should_ have done
it. I think Linus got sick of hearing these suggestions and began defending
his implementation decisions based on his experience and the running code.

------
api
<http://www.opendedup.org/>

Not a toy.

------
j_baker
Correct me if I'm wrong, but this is nothing new. We've known about these
limitations on FUSE for quite some time, haven't we?

------
treetrouble
sshfs isn't a toy

------
masto
Linus is increasingly becoming a crazy old man. I find his diatribes largely
irrelevant.

------
uriel
_cough_ Plan 9[1] _cough_

[1] <http://doc.cat-v.org/plan_9/4th_edition/papers/names>

~~~
sambeau
Interesting in light of Go:

    
    
      - New languages are needed for writing distributed/parallel applications
      `Needed', no.  `Helpful', perhaps.  The jury's still out.

~~~
uriel
Note that the Plan 9 team at the time were already working on Alef (
<http://doc.cat-v.org/plan_9/2nd_edition/papers/alef/> ) and would later
develop Limbo ( <http://doc.cat-v.org/inferno/4th_edition/limbo_language/> )
as the language for the Inferno distributed system (
<http://doc.cat-v.org/inferno/> )

