Re: [V9fs-developer] [PATCH 3/5] 9p: revert tsyncfs related changes

[Aneesh Kumar K.V]

On Tue, 29 Mar 2011 11:05:08 -0500, Eric Van Hensbergen <ericvh@xxxxxxxxx> wrote:
> On Sun, Mar 27, 2011 at 5:24 PM, Venkateswararao Jujjuri
> <jvrao@xxxxxxxxxxxxxxxxxx> wrote:
> >
> > Nice explanation. I looked at NFS and realized that they also follow
> > write_inode approach.
> > So I think you should make it explict that this will be helpful to dotl
> > also and may and TFSYNCFS
> > in the future if needed. With that I ack this.
> >
> 
> If this is something we really think we'll be adding back in the
> future, is there someway we can conditionalize its use (default off
> perhaps) so that if a particular server wanted to take advantage of
> it, they could.  This would seem preferable to just backing out the
> whole patch.

It would be a nice feature to request the server for feature bits and
then use different 9p operations with .L. ie if we can query the server
and find out whether it supports tsyncfs then we can probably skip fsync
during write_inode. The feature set is also useful to figure out which
acl model the client should enforce if we start supporting multiple acl
models and also to find out whether server also acl evaluation.
So i guess we should do this once we have something similar to
TFEATURE 9p operation

> 
> Another aspect which I didn't consider when we added it is what it
> would do to older versions of the servers which didn't have TFSYNCFS
> -- maybe this is a good case study for the .L graceful degredation
> plan we had talked about in the past where you try a tfsyncfs and if
> the server returns an error that it doesn't implement it you back off
> to another solution.
> 

With the current Qemu server, the server aborts when it gets a 9p
request that it didn't implement. That need to be fixed. Do you like to
see the above done as a part of new set of operations that we are going
to do, or are you suggesting that we need to do it for the existing set
looking at when we added the 9p operations ?.

-aneesh
--
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/