Messages in this thread | | | Date | Fri, 1 Jul 2005 09:18:59 -0500 | From | Eric Van Hensbergen <> | Subject | Re: FUSE merging? |
| |
On 7/1/05, Miklos Szeredi <miklos@szeredi.hu> wrote: > > I don't know where 9P "suffers" from being too generic, it's just > > well-designed and has done a good job of keeping things simple -- > > something that the plethora of over designed, bloated interfaces of > > today could learn from. > > True. I very much like the simplicity of the 9P protocol. But it's > system independence sometimes makes it fit poorly to the Linux VFS > interface. I guess you have a wide experience with this :) >
Yeah, but most of our problems had less to do with the VFS interface per se, and more to do with the dcache/page-cache. In the long run, the portability is something you may want though -- not only to provide support under BSD or whatever, but also to insulate changes in the VFS API from user file servers.
> > So it's much more important to reduce the number of round-trips for a > single operation, than multiplexing requests for multiple operations. >
Agreed, this will be something we'll (v9fs) have to keep a close tab on to keep things efficient.
> > With a proper mux there is no reason why v9fs can't be made as > > efficient as FUSE - and that's what we intend to demonstrate in > > v9fs-2.1. Plus, with v9fs you get the benefit of being able to > > export your synthetic file systems over the network with no > > additional copies. > > Yes, but does that matter? I'm not sure that it's a good idea > bundling network filesystem functionality together with userspace > filesystem functionality. Each has it's own set of requirements, and > it's own way of working optimally. >
I see your point, but increasingly common usage environments are distributed systems and I think network synthetics will have their niche.
> What would people say if ext3 was always mounted locally through NFS, > because the kernel would only provide the NFS filesystem client.
Probably the same thing they would say if ext3 was a user-space application that always needed to be mounted via FUSE ;)
> > Differentiation of interfaces depending on the "closeness" of the > client to the server makes good sense IMO. We currently have > in-kernel and across-network. FUSE adds in-userspace in between those > two. >
I think that remains to be seen. There is much to be gained from blurring the differentiation as we move Linux towards a first-class distributed system. If unified interfaces can be made "good-enough" performance wise, what justifies having multiple interfaces depending on network versus local? Specialization has its place, but performance mongering at the cost of design is what killed systems research. In the end, specialization has its place, but I think it's always worth striving towards unified interfaces when performance doesn't suffer to a great degree.
> > > Further, when you create an infrastructure which is meant to work over > > a network, you take fewer things for granted -- which ultimately leads > > to a more robust system capable of dealing with many of these > > problems. > > Yes. I'm not speaking agains v9fs, which I think has a valid niche, > as well as FUSE. >
FUSE certainly has its place, and has done a great job creating an environment in which it is relatively easy to create new file systems in user-space. My main point in responding was to take the position that the v9fs mechanisms are adequate to provide user-space file systems and that while it was not the primary motivation behind the v9fs project, we are actively pursuing improving the performance and robustness of our mechanisms for providing user-space (as well as kernel-space) file service and developing an SDK to ease the implementation of 9P-based synthetic file servers.
-eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |