[pnfs] client bug with boundary

Dean Hildebrand dhildebz at eecs.umich.edu
Tue Aug 29 15:17:11 EDT 2006


I found a bug which I think we kind of knew about, but didn't realize 
that it is a really big problem in the current code.  Thankfully, I 
think it has an easy fix.

When writing data (but a similar problem will probably occur on read 
too), the pages are all put into the page cache before LAYOUTGET is 
initiated.  This means that the 'boundary' value in the layout driver == 
0, which then means that the pNFS client does not coalesce data into 
chunks that don't cross stripe boundaries.  The coalesced chunks are 
never bigger than the wsize, which works out for us now since usually 
our stripe size is the same as the wsize, but the wsize'd chunks will 
cross stripe boundaries.  Not sure if anyone else has noticed this.

I noticed the problem when my application tried to do the following on 
the file system (2MB stripe size and wsize)

WRITE 1000000 at 7864320

This should be divided into 2 write requests to not exceed the 8388608 
byte stripe boundary: one of size 524288 and one of size 475712.  
Unfortunately, since boundary==0 and stripe_size==2MB, it is sent to the 
server as one write request for the entire size of 1000000.  For file 
layout with gpfs, this is just annoying, for netapp with distinct data 
servers, this will cause corruption.

Andy and I talked about this quickly and believe the fix is to issue the 
layoutget as soon as the pNFS client knows a I/O request is about to 
happen.  This way, all the information will be available for processing 
as the I/O request gets processed by the pNFS client.  The best place 
seems to be pnfs_file_read 
<ident?v=pnfs-2.6.17;i=pnfs_file_read>/write.  Issuing at open time 
solves the problem for some layouts too.  I think there may be some 
downsides for moving the layoutget to pnfs_file_read 
<ident?v=pnfs-2.6.17;i=pnfs_file_read>/write, such as the fact that the 
offset and extent will not match the actual request issued, but maybe we 
can discuss them tomorrow at the meeting.

-- 
Dean Hildebrand
Ph.D. Candidate
University of Michigan



More information about the pNFS mailing list