On Fri, Sep 12, 2014 at 10:22:11AM +0800, Peng Tao wrote: > > We never do I/O without a valid layout, but we keep the extents around > > because we need to keep state like that it's been written to or has > > a commit pending in a single place, and also need to keep it if a layout > > goes away temporarily. > We don't know if layout goes away temporarily or permanently. If > server happens to move the file's data (enterprise NAS does that for a > lot of reasons) in between, next time client does layoutget, it will > get a different extent mapping. I'm not sure if the new extent > tracking code is able to cope with it. The old code will certainly > fail though. A server is expected to do a layout recall with the clora_changed set to true if it moves data around and thus the layout goes away permanently. The Linux client currently irgnores that field, but that's something which needs to fixed in the core pnfs code and not the block layout drivers. But this isn't one of the cases were we keep the extent around but not the layout - those are the ones were we have stateid mismatches or similar (most of them now fixed by me). We actually have a much bigger elephant in the room, which this series doesn't address yet: if a layoutcommit fails we curently don't have a way to resend the data to the MDS. This will be more common pnfs core work as we basically need to keep the data in a state similar to NFS unstable writes, instead of claiming that we finished a NFS_FILE_SYNC, which allows the VM to drop the data from the pagecache before the commit happened. I'm slowly wading through all these issues - I initially only planned to write a server but so far fixing up the client has taken way more of my time compared to the relatively trivial server.. > If your concern is current layoutreturn implementation that ignores > pending layoutcommit (and inflight IOs), that needs to be fixed. I > have a patchset to fix it and it is still under internal QA. I'll post > it once it passes testing. That's a different issues, but I'm happy to review that as well. -- 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
