The COMMIT to the DS, ttbomk, commits data on the DS. I see it as orthogonal to updating the metadata on the MDS (but perhaps I'm wrong). As sjoshi@bluearc mentioned, the LAYOUTCOMMIT provides a synchronization point, so even if the non-clustered server does not want to update metadata on every DS I/O, the LAYOUTCOMMIT could also be a trigger to execute whatever synchronization mechanism the implementer wishes to put in the control protocol. -Dan > -----Original Message----- > From: Andy Adamson [mailto:andros@xxxxxxxxxx] > Sent: Tuesday, July 06, 2010 6:38 AM > To: Muntz, Daniel > Cc: sjoshi@xxxxxxxxxxx; linux-nfs@xxxxxxxxxxxxxxx; bhalevy@xxxxxxxxxxx > Subject: Re: 4.1 client - LAYOUTCOMMIT & close > > > On Jul 2, 2010, at 5:46 PM, <Daniel.Muntz@xxxxxxx> wrote: > > > By "extremely lame server" I assume you mean any pNFS server that > > doesn't have a cluster FS on the back end. > > No, I mean a pNFS file layout type server that depends upon > the 'hint' > of file size given by LAYOUTCOMMIT. This does not mean that the file > system has to be a cluster FS. > > If COMMIT through MDS is set, the MDS to DS protocol (be it a > cluster > FS or not) ensures the data is "commited" on the DSs. > LAYOUTCOMMIT is > not needed. > > If COMMITs are sent to the DSs (or FILE_SYNC writes), then > the MDS to > DS protocol (be it a cluster FS or not) should kick off a > back-end DS > to MDS communication to update the file size on the MDS. > > What I consider an 'extremely lame pNFS file layout server' is one > that requires COMMITs to the DS and then depends upon the > LAYOUTCOMMIT > to communicate the commited data size to the MDS. > > -->Andy > > > > So while this might work > > well for NetApp (as long as NetApp never ships a non-clustered > > pNFS), it > > might break others, or at least severely impact their > performance. > > For > > example, will the Solaris pNFS server work correctly without > > LAYOUTCOMMIT? IMHO, the client MUST issue the appropriate > > LAYOUTCOMMIT, > > but the server is free to handle it as a no-op if the server > > implementation does not need to utilize the payload. > > > > -Dan > > > >> -----Original Message----- > >> From: linux-nfs-owner@xxxxxxxxxxxxxxx > >> [mailto:linux-nfs-owner@xxxxxxxxxxxxxxx] On Behalf Of Andy Adamson > >> Sent: Friday, July 02, 2010 8:41 AM > >> To: Sandeep Joshi > >> Cc: linux-nfs@xxxxxxxxxxxxxxx; bhalevy@xxxxxxxxxxx > >> Subject: Re: 4.1 client - LAYOUTCOMMIT & close > >> > >> > >> On Jul 1, 2010, at 8:07 PM, Sandeep Joshi wrote: > >> > >> Hi Sandeep > >> > >>> > >>> In certain cases, I don't see layoutcommit on a file at all even > >>> after doing many writes. > >> > >> FYI: > >> > >> You should not be paying attention to layoutcommits - they have no > >> value for the file layout type. > >> > >> From RFC 5661: > >> > >> "The LAYOUTCOMMIT operation commits chages in the layout > represented > >> by the current filehandle, client ID (derived from the > session ID in > >> the preceding SEQUENCE operation), byte-range, and stateid." > >> > >> For the block layout type, this sentence has meaning in that > >> there is > >> a layoutupdate4 payload that enumerates the blocks that > have changed > >> state from being 'handed out' to being 'written'. > >> > >> The file layout type has no layoutupdate4 payload, and the > >> layout does > >> not change due to writes, and thus the LAYOUTCOMMIT call > is useless. > >> > >> The only field in the LAYOUTCOMMIT4args that might possibly > >> be useful > >> is the loca_last_write_offset which tells the server what > the client > >> thinks is the EOF of the file after WRITE. It is an extremely lame > >> server (file layout type server) that depends upon clients for this > >> info. > >> > >>> > >>> > >>> > >>> Client side operations: > >>> > >>> open > >>> write(s) > >>> close > >>> > >>> > >>> On server side (observed operations): > >>> > >>> open > >>> layoutget's > >>> close > >>> > >>> > >>> But, I do not see laycommit at all. In terms data written > >> by client > >>> it is about 4-5MB. > >>> > >>> When does client issue laycommit? > >> > >> The latest linux client sends a layout commit when the VFS does a > >> super_operations.write_inode call which happens when the > metadata of > >> an inode needs updating. We are seriously considering removing the > >> layoutcommit call from the file layout client. > >> > >> -->Andy > >> > >>> > >>> > >>> regards, > >>> > >>> Sandeep > >>> > >>> -- > >>> 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 > >> > >> -- > >> 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 > >> > >> > > > -- 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
