On Wed, Nov 08, 2017 at 07:08:25AM -0500, Jeff Layton wrote: > On Wed, 2017-11-08 at 14:30 +1100, NeilBrown wrote: > > What to people think of the following as an approach > > to Joshua's need? > > > > It isn't complete by itself: it needs a couple of changes to > > nfs-utils so that it doesn't stat the mountpoint on remount, > > and it might need another kernel change so that the "mount" system > > call performs the same sort of careful lookup for remount as the umount > > system call does, but those are relatively small details. > > > > Yeah, that'd be good. > > > This is the patch that you will either love of hate. > > > > With this patch, Joshua (or any other sysadmin) could: > > > > mount -o remount,retrans=0,timeo=1 /path > > > > and then new requests on any mountpoint from that server will timeout > > quickly. > > Then > > umount -f /path > > umount -f /path ... > Looks like a reasonable approach overall to preventing new RPCs from > being dispatched once the "force" umount runs. I've lost track of the discussion--after this patch, how close are we to a guaranteed force unmount? I assume there are still a few obstacles. > I do wonder if this ought to be more automatic when you specify -f on > the umount. Having to manually do a remount first doesn't seem very > admin-friendly. It's an odd interface. Maybe we could wrap it in something more intuitive. I'd be nervous about making "umount -f" do it. I think administrators could be unpleasantly surprised in some cases if an "umount -f" affects other mounts of the same server. --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
