On 15 Feb 2018, at 10:45, J. Bruce Fields wrote: > On Wed, Feb 14, 2018 at 09:15:05AM -0500, Benjamin Coddington wrote: >> On 14 Feb 2018, at 2:06, Harald Dunkel wrote: >> >>> Hi Ben, >>> >>> I take this as a "no serious problems by now". Good to hear. >>> Which kernel are you using? >> >> This was years ago on a 2.6.32 series. I don't expect you'll have >> serious problems now, either. As far as I know, my last employer is >> still using that architecture, but I couldn't tell you what software >> versions they're on now.. >> >> We moved to the knfsd-in-a-container from an architecture that was >> essentially a bunch of vanilla knfsds that could mount and any of >> the block devices, and block devices were tied to IP addresses, and >> this was all orchestrated by pacemaker. The problem with that one >> was that when a block device or filesystem was migrated, the server >> receiving that filesystem had to be put into grace, which disrupted >> any existing NFS serving that was going on. >> >> Test things, let us know how it works! > > I think you were using KVM, right, Ben? That's right. > Harald is talking about LXC, and there are still a few problems there. Ah, yes -- What a bonehead I am, I'd forgotten about containing the upcalls.. but if the state recovery db can be stored on the same filesystem as the container, and there's only one knfsd container per "host", then the HA model should still work I think. Ben > Jeff, do you object to going back to our plan B for reboot recovery (the > daemon)? The usermode helper containerization seems stalled and I have to > admit I'm probably not going to take it on myself. That might be the only > knfsd-in-a-container obstacle left. > > --b. -- 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
