On 2011-06-10 10:17, tao.peng@xxxxxxx wrote: > > -----Original Message----- > From: linux-nfs-owner@xxxxxxxxxxxxxxx [mailto:linux-nfs-owner@xxxxxxxxxxxxxxx] On Behalf Of Benny Halevy > Sent: Friday, June 10, 2011 8:36 PM > To: Peng, Tao > Cc: rees@xxxxxxxxx; bergwolf@xxxxxxxxx; linux-nfs@xxxxxxxxxxxxxxx; honey@xxxxxxxxxxxxxx > Subject: Re: [PATCH 87/88] Add configurable prefetch size for layoutget > > On 2011-06-10 01:36, tao.peng@xxxxxxx wrote: >> Hi, Benny, >> >> -----Original Message----- >> From: linux-nfs-owner@xxxxxxxxxxxxxxx [mailto:linux-nfs-owner@xxxxxxxxxxxxxxx] On Behalf Of Benny Halevy >> Sent: Friday, June 10, 2011 5:23 AM >> To: Jim Rees >> Cc: Peng Tao; linux-nfs@xxxxxxxxxxxxxxx; 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... Right and that's why the server has to be intelligent about it. Benny -- 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
