On Thu, 2020-12-03 at 13:51 -0500, bfields wrote: > On Thu, Dec 03, 2020 at 12:20:35PM +0000, Daire Byrne wrote: > > Just a small update based on the most recent patchsets from Trond & > > Bruce: > > > > https://patchwork.kernel.org/project/linux-nfs/list/?series=393567 > > https://patchwork.kernel.org/project/linux-nfs/list/?series=393561 > > > > For the write-through tests, the NFSv3 re-export of a NFSv4.2 > > server > > has trimmed an extra GETATTR: > > > > Before: originating server <- (vers=4.2) <- reexport server - > > (vers=3) > > <- client writing = WRITE,COMMIT,GETATTR .... repeating > > > > After: originating server <- (vers=4.2) <- reexport server - > > (vers=3) > > <- client writing = WRITE,COMMIT .... repeating > > > > I'm assuming this is specifically due to the "EXPORT_OP_NOWCC" > > patch? > > Probably so, thanks for the update. > > > All other combinations look the same as before (for write-through). > > An > > NFSv4.2 re-export of a NFSv3 server is still the best/ideal in > > terms > > of not incurring extra metadata roundtrips when writing. > > > > It's great to see this re-export scenario becoming a better > > supported > > (and performing) topology; many thanks all. > > I've been scratching my head over how to handle reboot of a re- > exporting > server. I think one way to fix it might be just to allow the re- > export > server to pass along reclaims to the original server as it receives > them > from its own clients. It might require some protocol tweaks, I'm not > sure. I'll try to get my thoughts in order and propose something. > It's more complicated than that. If the re-exporting server reboots, but the original server does not, then unless that re-exporting server persisted its lease and a full set of stateids somewhere, it will not be able to atomically reclaim delegation and lock state on the server on behalf of its clients. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
