Thread (16 messages) 16 messages, 3 authors, 2023-04-20

Re: [RFC][PATCH 0/2] Monitoring unmounted fs with fanotify

From: Christian Brauner <brauner@kernel.org>
Date: 2023-04-18 13:33:47
Also in: linux-fsdevel

On Fri, Apr 14, 2023 at 09:29:01PM +0300, Amir Goldstein wrote:
Jan,

Followup on my quest to close the gap with inotify functionality,
here is a proposal for FAN_UNMOUNT event.

I have had many design questions about this:
I'm going to humbly express what I feel makes sense to me when looking
at this from a user perspective:
1) Should we also report FAN_UNMOUNT for marked inodes and sb
   on sb shutdown (same as IN_UNMOUNT)?
My preference would be if this would be a separate event type.
FAN_SB_SHUTDOWN or something.
2) Should we also report FAN_UNMOUNT on sb mark for any unmounts
   of that sb?
I don't think so. It feels to me that if you watch an sb you don't
necessarily want to watch bind mounts of that sb.
3) Should we report also the fid of the mount root? and if we do...
4) Should we report/consider FAN_ONDIR filter?

All of the questions above I answered "not unless somebody requests"
in this first RFC.
Fwiw, I agree.
Specifically, I did get a request for an unmount event for containers
use case.

I have also had doubts regarding the info records.
I decided that reporting fsid and mntid is minimum, but couldn't
decide if they were better of in a single MNTID record or seprate
records.

I went with separate records, because:
a) FAN_FS_ERROR has set a precendent of separate fid record with
   fsid and empty fid, so I followed this precendent
b) MNTID record we may want to add later with FAN_REPORT_MNTID
   to all the path events, so better that it is independent
I agree.
There is test for the proposed API extention [1].

Thoughts?
I think this is a rather useful extension!
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help