From: Roger W. <ro...@fi...> - 2007-07-14 15:55:42
|
>> An unrelated question: how come the FUSE NFS export hooks didn't make it >> into the kernel? Is there some fundamental problem preventing that or >> just the usual LKML "time, love and tenderness"? 8-) > My tuppence worth, having used the lowlevel fuse interface to export a clustered filesystem over nfs > It was decided, that NFS exporting a userspace filesystem is best done > in userspace, which makes a lot of sense. > It does make sense, but if it's cohabiting with a kernel-space nfs, clients need to specify a different port number which is not a good customer experience. nfs export should 'just work' or it's not really nfs export. > I did some experimentation with it, but it is nowhere near usable > stage. > I've had reasonable success in exporting a multi-terabyte clustered filestore. There are a few gotcha's: + you can't satisfy incoming nfs->fuse requests by making local nfs requests from the fuse userspace driver (so no simple man-in-the-middle attacks) - it locks up almost instantly + bad things happen (i.e. kernel memory corruption) if you reload the fuse kernel module. + implementing the getattr and (hard) link calls (when the target device is a 'real' filesystem) needs a source /path/ but you only get a source inode number, even though the original syscall (e.g. link) specified a full path. The nfs side passes in a parent directory inode number (which allows you to generate a path) but this is also lost by the time it gets to fuse userspace. (So can you pass through the parent i-number please). + I've not tested it in a low memory situation, but it's probably no worse than fuse itself. > And it isn't often requested, probably because the out-of-tree module > still supports it. I promised myself to drop support for the > out-of-tree module in fuse-3.0, so that will be a good time to start > working seriously on userspace NFS exporting ;) > Consider it requested :-) But if there was a good boilerplate userspace nfs driver there would be no need for fuse. You could just loopback mount the userspace nfs filesystem to make it visible locally (although that's another opportunity for deadlock). hmm: http://www.usenix.org/publications/library/proceedings/usenix01/mazieres/mazieres.pdf It still doesn't solve the 'it's not really nfs if it's on a different port number' problem though. -- Roger |