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. Thanks, Tao ��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
