On Sat, Mar 23, 2019 at 09:32:08AM +1100, NeilBrown wrote: > On Fri, Mar 22 2019, J. Bruce Fields wrote: > > I've gotten complaints about the same thing and said "well, in > > retrospect we shouldn't have designed the interface this way, but we > > did, so just stop opening those files". > > As the fool who actually "designed" this, Pretty sure I was there too and had my chance to object. In any case, hope you didn't take that as a personal complaint about your work, it (along with lots of maintenance since then) is much appreciated. > I can say with some confidence that the intention was always the > requests would block for at most 30 seconds. ... > > One advantage of waiting for mountd to come back is that you could > > upgrade mountd in place. That shouldn't take 30 seconds, though. And I > > haven't heard of anyone actually doing that. > > Surely upgrading of mountd in-place happens whenever you install a new > version. I didn't think distros restarted mountd on upgrade, but I haven't actually checked that. I agree that it's something we should allow, anyway. > > It's too bad that not opening auth.unix.gid is the only way for mountd > > to communicate that gids shouldn't be mapped. > > I have a general preference for reusing existing functionality rather > than creating new special-purpose functionality. I think this has > served me well more often than not. Maybe this is one case of "not". > > If you want to restart mountd without --managed-gids (where previously > it had that option), there is a chance that you will hit this problem. > That is a case where the answer "just stop opening those files" doesn't > really apply. Yeah. OK, applying. (But I'm traveling and may not get this tested and pushed out till next week.) --b.
