Trond Myklebust wrote: [stuff snipped] I'll admit I hadn't seen this errata before. However, it seems to be specific to the File Layout. For the Flexible File Layout... When I look in RFC-8435, I cannot find anything that states that a LayoutCommit is only required for case(s) where a Commit to the Storage Server is required. Sec. 2.1 Clearly states that a Commit to the Storage Server is required before the client does a LayoutCommit when the write(s) were not done FILE_SYNC. However, I do not see any indication that the LayoutCommit is not to be done for the case where the write(s) are done FILE_SYNC. FF_FLAGS_NO_LAYOUTCOMMIT can be used to indicate to a client that LayoutCommits are not required, but this does not be dependent on how the write(s) to the Storage Server were done. The only way a Flexible File layout Metadata server can know what the current file size is (when a read/write layout is issued to a client) is to do a Getattr to the Storage Server. If a client is not required to do a LayoutCommit when the write(s) to the Storage Server are done FILE_SYNC, then the Metadata server must do Getattr RPCs to the Storage Server whenever it needs an up to date file size if a read/write layout is issued to a client. This can result in a lot of overhead that can be avoided by requiring the LayoutCommit to be done by a client after writing to a Storage Server, irrespective of the need for a Commit to the Storage Server. As such, I would rather not have this errata applied to RFC-8435. rick