[pnfs] The Boundary issue

[Marc Eshel]

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