| |||||||||||||
Another Linux capabilities hole foundAnother Linux capabilities hole foundPosted Apr 16, 2009 11:55 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)In reply to: Another Linux capabilities hole found by michaeljt Parent article: Another Linux capabilities hole found
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.
(Log in to post comments)
Another Linux capabilities hole found Posted Apr 16, 2009 14:45 UTC (Thu) by bfields (subscriber, #19510) [Link] 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 Posted Apr 16, 2009 14:48 UTC (Thu) by ajb (subscriber, #9694) [Link]
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 Posted Apr 17, 2009 7:44 UTC (Fri) by michaeljt (subscriber, #39183) [Link]
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]
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 michaeljt (subscriber, #39183) [Link]
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
|
|||||||||||||