> -----Original Message----- > From: 'bfields' [mailto:bfields@xxxxxxxxxxxx] > Sent: Wednesday, November 25, 2020 11:03 AM > To: Frank Filz <ffilzlnx@xxxxxxxxxxxxxx> > Cc: 'Daire Byrne' <daire@xxxxxxxx>; 'Trond Myklebust' > <trondmy@xxxxxxxxxxxxxxx>; 'linux-cachefs' <linux-cachefs@xxxxxxxxxx>; > 'linux-nfs' <linux-nfs@xxxxxxxxxxxxxxx> > Subject: Re: Adventures in NFS re-exporting > > On Wed, Nov 25, 2020 at 08:25:19AM -0800, Frank Filz wrote: > > On the other > > hand, re-export with state has a pitfall. If the re-export server > > crashes, the state is lost on the original server unless we make a > > protocol change to allow state re-export such that a re-export server > > crashing doesn't cause state loss. > > Oh, yes, reboot recovery's an interesting problem that I'd forgotten about; > added to that wiki page. > > By "state re-export" you mean you'd take the stateids the original server > returned to you, and return them to your own clients? So then I guess you > wouldn't need much state at all. By state re-export I meant reflecting locks the end client takes on the re-export server to the original server. Not necessarily by reflecting the stateid (probably something to trip on there...) (Can we nail down a good name for it? Proxy server or re-export server work well for the man in the middle, but what about the back end server?) Frank > > For this reason, I haven't rushed to implement lock state re-export in > > Ganesha, rather allowing the re-export server to just manage lock > > state locally. > > > > > Cooperating servers could have an agreement on filehandles. And I > > > guess > > we > > > could standardize that somehow. Are we ready for that? I'm not > > > sure what other re-exporting problems there are that I haven't thought of. > > > > I'm not sure how far we want to go there, but potentially specific > > server implementations could choose to be interoperable in a way that > > allows the handle encapsulation to either be smaller or no extra > > overhead. For example, if we implemented what I've thought about for > > Ganesha-Ganesha re-export, Ganesha COULD also be "taught" which > > portion of the knfsd handle is the filesystem/export identifier, and > > maintain a database of Ganesha export/filesystem <-> knfsd > > export/filesystem and have Ganesha re-encapsulate the > > exportfs/name_to_handle_at portion of the handle. Of course in this > > case, trivial migration isn't possible since Ganesha will have a different > encapsulation than knfsd. > > > > Incidentally, I also purposefully made Ganesha's encapsulation > > different so it never collides with either version of knfsd handles > > (now if over the course of the past 10 years another handle version has come > along...). > > I don't think anything's changed there. > > --b.
