On Mon, Jun 17, 2019 at 1:46 PM Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > On Mon, 2019-06-17 at 13:32 -0700, Patrick Donnelly wrote: > > On Mon, Jun 17, 2019 at 5:56 AM Yan, Zheng <zyan@xxxxxxxxxx> wrote: > > > After mds evicts session, file locks get lost sliently. It's not safe to > > > let programs continue to do read/write. > > > > I think one issue with returning EIO on a file handle that did hold a > > lock is that the application may be programmed to write to other files > > assuming that lock is never lost, yes? In that case, it may not ever > > write to the locked file in any case. > > > > Sure, applications do all sorts of crazy things. We can only cater to so > much craziness. I'll assert that most applications don't have these > sorts of weirdo usage patterns, and an error on read/write is more > reasonable. It wouldn't surprise me if it's a niche use case, but I hear about a *lot* of applications which know they're running on a distributed fs using file locks as a primitive leader election to select amongst multiple processes (this happens a lot not only in HPC, but also in distributed database and/or compute projects). That tends to involve precisely what Patrick is describing. Given that as you've said SIGLOST doesn't actually exist in Linux I don't have a good alternative, but if there was some more proactive way we could tell the application (or let applications enable a more proactive way, like getting EIO on any file access once a lock is lost?) it would probably be good. > > Note that this behavior is already documented in fcntl(2) as well, as is > SIGLOST not being implemented. > > > Again, I'd like to see SIGLOST sent to the application here. Are there > > any objections to reviving whatever patchset was in flight to add > > that? Or just writeup a new one? > > > > I think SIGLOST's utility is somewhat questionable. Applications will > need to be custom-written to handle it. If you're going to do that, then > it may be better to consider other async notification mechanisms. > inotify or fanotify, perhaps? Those may be simpler to implement and get > merged. > -- > Jeff Layton <jlayton@xxxxxxxxxx> >
