[pnfs] The Boundary issue
Benny Halevy
bhalevy at panasas.com
Fri Sep 29 02:36:14 EDT 2006
Marc, the problem with waiting as long as possible with layoutget, until
flush is that it adds latency to flush and this hurts applications that
either
block on fsync or close, or just writing enough data so they fill the cache
and then wait behind the syncer to free up memory so they can write more.
In this case getting a layout on write vs. on sync when either you have
enough dirty data for the file or you're low on memory can help establish
a pipeline where you'll already have a layout in hand (or at least a
layoutget
on the wire) when you need to flush.
More intelligence can be put into the byte range you ask for. The client
can detect sequential access (for either read or write) and adjust the
requested
byte ranges accordingly. The layout driver or the file system can also
adjust
the layout according to the file striping.
Benny
Marc Eshel wrote:
> Hi Rahul,
> The point of not getting layout with file open is to wait and see how much
> we have to write and only above some limit we get the layout. I prefer the
> option of getting the layout at open time but the other option of getting
> it at IO time should be done as late as possible, so waiting for flush
> (like it is done now) is a better approach. We have a better idea of how
> much we need to write. Did you look at how complicated it will be to break
> the write to multiple DSs if the write size is above stipe size?
> Marc.
>
> pnfs-bounces at linux-nfs.org wrote on 09/28/2006 03:43:56 PM:
>
>
>> Hi Guys,
>> I was looking at the boundary issue. It seem rather simple to fix in the
>> read/write code paths. There seem to be 2 solutions:
>>
>> 1.
>> In both the read and write code paths, NFSPROTO(inode)->boundary(). This
>> pointer points to pnfs_getboundary(). This function checks whether there
>> is a layout. If there is one, it returns the stripesize present in the
>> file (via a call to the layout driver's getstripesize function). In the
>> absence of a layout pnfs_getboundary returns 0. In both the read and
>> write cases, pnfs_getboundary() is called prior to making the request
>> structs. So, we could call layoutget here and we'd be done.
>>
>> 2.
>> The other approach is similar to what Benny mentioned. Get the layout on
>> the write path (pnfs_file_write) rather than the flush path. Similarly
>> for the read. In fact, this call is alredy being done to handle the non
>> page cache I/O. All we need to do is move it further up in the function
>> before the calls for the page cache based I/O.
>>
>> Regards
>> Rahul
>>
>> _______________________________________________
>> pNFS mailing list
>> pNFS at linux-nfs.org
>> http://linux-nfs.org/cgi-bin/mailman/listinfo/pnfs
>>
>
> _______________________________________________
> pNFS mailing list
> pNFS at linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/pnfs
>
More information about the pNFS
mailing list