On Tue, Nov 10, 2015 at 05:13:53PM +0530, Soumya Koduri wrote: > > > On 11/10/2015 01:50 AM, J. Bruce Fields wrote: > >On Mon, Nov 09, 2015 at 09:36:03PM +0530, Soumya Koduri wrote: > >>Hi, > >> > >> From the code looks looks like, we block the following FOPs while the > >>NFS server is in grace (which have 'nfs_in_grace' check)- > >> > >>NFSv3 - > >>SETATTR > >> > >>NLM - > >>LOCK > >>UNLOCK > >> > >>NFSv4 - > >>OPEN > >>LOCK > >>REMOVE > >>RENAME > >>SETATTR > >> > >>Request clarification behind selecting these fops. Dan confirmed that > >>'as per 5661 RFC, RENAME and REMOVE should be denied during grace to > >>support volatile file handles (which we don't support...). > > > >RENAME and REMOVE also conflict with delegations. So I think you don't > >want to allow those till clients have recovered their delegations (or > >discovered that they can't). > > > >I think LINK belongs on that list for similar reasons. > > > > Thanks Bruce. What about NFSv3 fops? I can see I/Os going on even > with kernel-NFS while the server is in grace (haven't checked with > delegations though)
Yes, the grace period should really block v3 ops too. It can't block opens, obviously (there aren't any v3 opens), but it should block specific operations that would conflict with recoverable v4 state. That said, Linux knfsd currently *doesn't* do most of that. (I believe it's only blocking NLM lock/unlock). I think that's a bug. But that means I don't have much experience yet with what it would mean to turn this on. People aren't used to v3 blocking on the grace period (unless they do a lot of file locking), so you'd want to be careful to minimize the impact, I think--e.g. make sure the server knows not to enforce these things if there are no NFSv4 clients to recover. --b. > > -Soumya > > >--b. > > > > > >> > >>And from RFC 3530 - > >><snippet> > >>8.6.2. Server Failure and Recovery > >> > >> If the server loses locking state (usually as a result of a restart > >> or reboot), it must allow clients time to discover this fact and re- > >> establish the lost locking state. The client must be able to re- > >> establish the locking state without having the server deny valid > >> requests because the server has granted conflicting access to another > >> client. Likewise, if there is the possibility that clients have not > >> yet re-established their locking state for a file, the server must > >> disallow READ and WRITE operations for that file. The duration of > >> this recovery period is equal to the duration of the lease period. > >> > >>..... > >>..... > >>..... > >> > >> The period of special handling of locking and READs and WRITEs, equal > >> in duration to the lease period, is referred to as the "grace > >> period". During the grace period, clients recover locks and the > >> associated state by reclaim-type locking requests (i.e., LOCK > >> requests with reclaim set to true and OPEN operations with a claim > >> type of CLAIM_PREVIOUS). During the grace period, the server must > >> reject READ and WRITE operations and non-reclaim locking requests > >> (i.e., other LOCK and OPEN operations) with an error of > >> NFS4ERR_GRACE. > >> > >></snippet> > >> > >>Does it mean that the NFS server need to reject I/Os as well unless it > >>is sure that there can be no other reclaim-type LOCK/OPEN requests? Also > >>why is SETATTR handled specially unlike WRITE fop. > >> > >>Thanks, > >>Soumya > >> > >>------------------------------------------------------------------------------ > >>Presto, an open source distributed SQL query engine for big data, initially > >>developed by Facebook, enables you to easily query your data on Hadoop in a > >>more interactive manner. Teradata is also now providing full enterprise > >>support for Presto. Download a free open source copy now. > >>http://pubads.g.doubleclick.net/gampad/clk?id=250295911&iu=/4140 > >>_______________________________________________ > >>Nfs-ganesha-devel mailing list > >>Nfs-ganesha-devel@lists.sourceforge.net > >>https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel ------------------------------------------------------------------------------ _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
