LWN: Comments on "Another Linux capabilities hole found"

Ever further off topic :)

nix — Wed, 22 Apr 2009 22:57:13 +0000

Of course Linux caches file data: in fact it won't work without it.
Absolutely everything that gets put in a page in memory (all file data,
anonymous mmaped pages, you name it) has to pass through the page cache
first. Executables *run* from the page cache: their text pages reside
nowhere else.

There *is* a cache of disk blocks (the buffer cache), but these days it's
used pretty much entirely for metadata (as this doesn't necessarily have a
page in memory devoted to it).

Ever further off topic :)

mjthayer — Wed, 22 Apr 2009 09:20:25 +0000

Does Linux actually cache file data, or only block data? I would have thought that user space filesystem latency could be reduced quite a bit by clever caching - the kernel caches data from file reads (with a bit of read-ahead), and writes to files, and sends them to the user space filesystem as a package. If the filesystem has an underlying block device, this could be done shortly before the block device cache is due to be flushed.

Another Linux capabilities hole found

i3839 — Sat, 18 Apr 2009 17:05:14 +0000

Local network latency is very low, much lower than hard disk latencies. Throughput is about 100 MB/s, as fast as fast hard disks. The only reason it's slower is because there's a slow local fs at the other end.

Fundamental issue is that programs use system calls to communicate with the outside world, and most of those system calls deal (sometimes indirectly) with files. For a network filesystem client going through the kernel, then to userspace and back again is just a stupid way of doing something relatively simple.

To sum up, network filesystem clients are in-kernel for all the same reasons why normal filesystems are in-kernel. For network fs servers it's a slightly different trade-off.

Another Linux capabilities hole found

mjthayer — Fri, 17 Apr 2009 07:44:32 +0000

Are these fundamental issues though, or things that can be fixed? Bearing in mind, as I said, that a network fs will be slower than a local one anyway (until networks reach the speed of a local bus that is...) And do you think that it would still be good to keep network filesystems in the kernel if it were possible to put them in user space?

Another Linux capabilities hole found

ajb — Thu, 16 Apr 2009 14:48:29 +0000

There are other non-kernel nfs implementations. vesta (vestasys.org) has one which they claim is faster than the in-kernel implementation. There is also http://nfs-ganesha.sourceforge.net/

Another Linux capabilities hole found

bfields — Thu, 16 Apr 2009 14:45:43 +0000

Also, note the problem here was on the *server* side, not the client. And the question of why the server is in the kernel is also interesting, but irrelevant in this case since the userspace server was equally affected by this bug--the userspace server uses setfsuid(), which uses the same mask bits as the in-kernel nfsd is using.

Another Linux capabilities hole found

Cyberax — Thu, 16 Apr 2009 11:55:00 +0000

FUSE is not ready to replace native filesystems. It's far slower than real in-kernel FS, less powerful and can have some consistency problems.

Another Linux capabilities hole found

mjthayer — Thu, 16 Apr 2009 08:48:38 +0000

I wonder why we still need network filesystems in the kernel? The traditional reason was to allow for using nfs as a root partition, but surely with FUSE and an initramfs (and perhaps a bit of work to make them usable in this context) this is no longer such an important reason? And given the inherent latency of a network filesystem, the extra performance can't be a valid reason either.

Disclaimer: I am speaking as a naive outsider, not a clueful kernel dev.