Re: FUSE merging?

[Eric Van Hensbergen]

On 7/1/05, Miklos Szeredi <miklos@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/