Hi, > -----Original Message----- > From: linux-nfs-owner@xxxxxxxxxxxxxxx [mailto:linux-nfs-owner@xxxxxxxxxxxxxxx] > On Behalf Of tao.peng@xxxxxxx > Sent: Tuesday, November 01, 2011 1:29 PM > To: Trond.Myklebust@xxxxxxxxxx; rees@xxxxxxxxx > Cc: bhalevy@xxxxxxxxxx; bergwolf@xxxxxxxxx; linux-nfs@xxxxxxxxxxxxxxx; > nfsv4@xxxxxxxx > Subject: RE: [PATCH 2/2] nfs41: handle BLK_LAYOUT CB_RECALL_ANY > > Hi, Trond, > > > -----Original Message----- > > From: Trond Myklebust [mailto:Trond.Myklebust@xxxxxxxxxx] > > Sent: Tuesday, November 01, 2011 2:40 AM > > To: Jim Rees > > Cc: Benny Halevy; Peng Tao; linux-nfs@xxxxxxxxxxxxxxx; Peng, Tao; nfsv4 list > > Subject: Re: [PATCH 2/2] nfs41: handle BLK_LAYOUT CB_RECALL_ANY > > > > On Mon, 2011-10-31 at 14:31 -0400, Jim Rees wrote: > > > Trond Myklebust wrote: > > > > > > I don't necessarily disagree with what you are saying, but I have yet to > > > see a single server side implementation of CB_RECALL_ANY, let alone any > > > numbers that indicate performance or responsiveness problems resulting > > > from our existing client-side implementation. > > > > > > I therefore find it hard to understand why optimising this particular > > > code is such a high priority, or why a patch that is adding per-file > > > layoutreturns to initiate_bulk_draining() is going to help anything at > > > all. > > > > > > Testing between the linux block layout client and the EMC block layout > > > server revealed a deadlock when the server had handed out some number of > > > layouts and couldn't hand out any more. So now the EMC block layout server > > > implements CB_RECALL_ANY. So yes, this solves a real world problem, and > > > yes, there is a server that implements this. > > > > > > We had some discussions at the time, and I don't remember if those were on > > > the linux-nfs list or in some other forum. We decided that the client was > > > in the best position to decide which layouts were no longer needed, so we > > > needed some way for the server to tell the client to return some layouts > > > without specifying which ones. CB_RECALL_ANY seemed custom-made for this > > > purpose, so we used it. > > > > > > I don't think it would be appropriate for the server to recall all layouts > > > when it only needs some of them back. > > > > As I said previously: the current client implementation deals with > > CB_RECALL_ANY by calling initiate_file_draining(), which forgets _all_ > > layouts. If that is what we want to continue to use, then sending > > layoutreturn with LAYOUTRETURN4_ALL is appropriate. > > Otherwise, please fix the client to be more selective (in which case > > LAYOUTRETURN4_FILE may be more appropriate) and please remember to > > provide performance numbers to justify the need for optimisation. > OK, fair enough. I will work on the selective layoutreturn approach when I have the > time slot. And I agree it is of low priority. I heard that there are some discussions about this in last pnfs Linux status meeting. Sorry I wasn't in the meeting but please someone update briefly what the conclusion is? Is the above solution still valid? Just don't want to go wrong direction again... :-P Thanks, Tao ��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
