On Fri, Apr 14, 2023 at 03:01:01PM -0400, Benjamin Coddington wrote: > On 14 Apr 2023, at 12:41, Trond Myklebust wrote: > > > > I mean both cases. Doing a lazy umount with a hard mounted filesystem is a risk sport: if the server does become permanently borked, you can fill up your page cache with stuff that can’t be evicted. Most users don’t realise this, so they get confused when it happens (particularly since the filesystem is out-of-sight and hence out-of-mind). > > I've been pecking away at a sysfs knob for this case. Seemed a clearer path to destruction. > > >> > >> Note, BTW, that hard vs. soft is a property of fs instance; if you have > >> it present elsewhere in the mount tree, flipping it would affect all > >> such places. I don't see any good way to make it a per-mount thing, TBH… > > > > > > The main use case is for when the server is permanently down, so normally it shouldn’t be a problem with flipping the mode on all instances. > > Is there another case? Because, if so.. > > > That said, it might be nice to make it per-mountpoint at some time. > > We do have the ability to declare individual RPC calls to time out, > > so it’s doable at the RPC level. All we would really need is the > > ability to store a per-vfsmount flag. I would very much like to avoid having filesystem specific data in struct vfsmount. That sounds like a maintenance nightmare going forward. Mount structures should remain pure vfs constructs that only carry generic properties imho. > > .. maybe vfsmount's mnt_root d_fsdata? I don't think that would work without having access to the vfsmount.
