On Tue, Nov 03, 2009 at 05:37:22PM +0800, Mi Jinlong wrote: > Hi Bruce > > Thanks for your answer. > > J. Bruce Fields: > > On Mon, Nov 02, 2009 at 05:28:02PM +0800, Mi Jinlong wrote: > >> Hi Trond et al: > >> > > ..snip.. > > >> Server reply ENOLCK for WL1 to client because nfslock service stoped, > > > > I don't completely understand that part: is it because the monitor call > > to statd fails? > > yes. > > > > >> but it can not distinguish retransmited request with normal request, > >> so it reply OK for WL1_re to client after nfslock service start. But > >> fcntl client called will return when it receive WL1.reply, WL1_re.reply > >> will be droped at Client. So that, the lock between client and server > >> is different. When client send a some lock request to server again, > >> it will get a EBLOCKD error from Server. > > > > But, OK, I get the idea, and generic DRC code shared by nfsd and nlm > > makes sense to me; thanks for looking into this. > > In my patch, the generic DRC code as a part of sunrpc, is it ok? or we > should put it at fs/nfs_common? Sunrpc makes sense to me; this should be purely rpc-level code without any special knowledge of nfs. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
