On Tue, 21 Sept 2021 at 17:00, Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > > Any recommended workarounds? Or does this simply mean that > > administrators need to notify client users to unmount (or > > at least stop their workloads) before rebooting the proxy? > > I think so. > > If you don't use any file locking or delegations I suppose you're also > OK. Delegations might be useful, though. > > I'd expect reexport to be useful mainly for data that changes very > rarely, if that helps. > > --b. Firstly, it's great to see this documentation and the well maintained wiki page for something we use in production (a lot) - thanks Bruce! I can only draw on our experience to say: * if the nfs re-export server doesn't crash, we rarely have cause to reboot it. * we re-export read-only software repositories to WAN/cloud instances (an ideal use case). * we also re-export read/write production storage but every client process is writing unique files - there are no writes to the same file(s) from any clients of the re-export server. We don't use or need crossmnt functionality, but I know from chatting to others within our industry that the fsid/crossmnt limitation causes them the most grief and confusion. I think in the case of Netapps, there are similar problems with trying to re-export a namespace made up of different volumes? As noted on the wiki, the only way around that is probably to have a "proxy" mode (similar to what ganesha does?). Daire
