Another Linux capabilities hole found

Posted Apr 17, 2009 7:44 UTC (Fri) by mjthayer (guest, #39183)
In reply to: Another Linux capabilities hole found by Cyberax
Parent article: Another Linux capabilities hole found

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

Posted Apr 18, 2009 17:05 UTC (Sat) by i3839 (guest, #31386) [Link] (2 responses)

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.

Ever further off topic :)

Posted Apr 22, 2009 9:20 UTC (Wed) by mjthayer (guest, #39183) [Link] (1 responses)

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.

Ever further off topic :)

Posted Apr 22, 2009 22:57 UTC (Wed) by nix (subscriber, #2304) [Link]

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).