Return-Path: Received: from mexforward.lss.emc.com ([128.222.32.20]:21517 "EHLO mexforward.lss.emc.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756586Ab1FJOR3 convert rfc822-to-8bit (ORCPT ); Fri, 10 Jun 2011 10:17:29 -0400 From: To: CC: , , , Date: Fri, 10 Jun 2011 10:17:01 -0400 Subject: RE: [PATCH 87/88] Add configurable prefetch size for layoutget Message-ID: References: <09142112ff0115f7f22124a69ead7b9bb5e0958f.1307464382.git.rees@umich.edu> <4DEED80A.4000102@panasas.com> <20110608021852.GA20998@merit.edu> <4DF062D6.7010304@panasas.com> <20110609114929.GA28157@merit.edu> <4DF0CB5D.60000@panasas.com> <20110609135846.GA32565@merit.edu> <4DF139D0.1080200@tonian.com> <4DF20FB3.6030603@tonian.com> In-Reply-To: <4DF20FB3.6030603@tonian.com> Content-Type: text/plain; charset="us-ascii" Sender: linux-nfs-owner@vger.kernel.org List-ID: MIME-Version: 1.0 -----Original Message----- From: linux-nfs-owner@vger.kernel.org [mailto:linux-nfs-owner@vger.kernel.org] On Behalf Of Benny Halevy Sent: Friday, June 10, 2011 8:36 PM To: Peng, Tao Cc: rees@umich.edu; bergwolf@gmail.com; linux-nfs@vger.kernel.org; honey@citi.umich.edu Subject: Re: [PATCH 87/88] Add configurable prefetch size for layoutget On 2011-06-10 01:36, tao.peng@emc.com wrote: > Hi, Benny, > > -----Original Message----- > From: linux-nfs-owner@vger.kernel.org [mailto:linux-nfs-owner@vger.kernel.org] On Behalf Of Benny Halevy > Sent: Friday, June 10, 2011 5:23 AM > To: Jim Rees > Cc: Peng Tao; linux-nfs@vger.kernel.org; peter honeyman > Subject: Re: [PATCH 87/88] Add configurable prefetch size for layoutget > > On 2011-06-09 06:58, Jim Rees wrote: >> Benny Halevy wrote: >> >> > My understanding is that layoutget specifies a min and max, and the server >> >> There's a min. What do you consider the max? >> Whatever gets into csa_fore_chan_attrs.ca_maxresponsesize? >> >> The spec doesn't say max, it says "desired." I guess I assumed the server >> wouldn't normally return more than desired. > > No, the server may freely upgrade the returned layout segment by returning > a layout for a larger byte range or even returning a RW layout where a READ > layout was asked for. > [PT] It is true that server can upgrade the layout segment freely. But there is always a price to pay. Server has to be dealing with all kind of clients. > If server returns more than being asked for, it may hurt other clients. And if all clients ask for more than they need and the server just gives it to them, what do you get out of that? [PT] We cannot avoid this even if client has automatic layout prefetch algorithem implemented... think about all clients are doing sequential IO... -Tao