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. > 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.
