[systemd-devel] [PATCH v2 5/5] mount: auto-detect iSCSI and FCoE as requiring network

[Lennart Poettering]

On Wed, 17.12.14 13:13, Karel Zak (kzak at redhat.com) wrote:

> On Fri, Dec 12, 2014 at 08:11:54PM +0100, Lennart Poettering wrote:
> > > I guess it's enough to add the 'fd' to systmed sd_event_add_io() and
> > > call mnt_table_parse_mtab() when a change is detected. (As already
> > > implemeted in the original Chris' patch.)
> > 
> > Karel, if I got this right, then the new monitor stuff will only wrap
> > inotify on utab, right? I think it would be useful if it would also
> > abstract notifications via /proc/self/mountinfo in it. To make the
> > interface easy for this and to be able to just hand out a single fd,
> > this would mean creating an epoll fd inside the lib, then adding the
> > inotify fd for utab to it, and then on top the EPOLLPRI watch on
> > /proc/self/mountinfo.
> > 
> > This way apps would get the full set of notifications via your
> > library, without knowing what's going on underneath, and userspace
> > notifications and kernel notifications would come the same way. 
> 
> OK, implemented (util-linux "monitor" branch on github).
> 
> But I have changed the userspace monitor to care about
> /run/mount/utab.lock file. It's better than the original Chris idea
> (monitor all /run/mount directory for utab rename changes).  This new
> solution is without possible false positives. 

Not following here. As long as everybody writing utab moves the file
atomically into place I see no reason to watch the lock file ever.

> 
> This is important details, because if you use epoll file descriptor 
> in another epoll then you're correctly notified on the top-level epoll, 
> but you lost information about which underneath file descriptor is active 
> -- then it was impossible to verify the inotify IN_MOVED_TO utab
> event.

Hmm? Not following. The top-level epoll will get an event telling you
that which low-level epoll is triggered. Then, you read an event from
that which tells you precisely which actual file has been triggered...

> The another advantage is that the event is triggered really after utab
> update (the update is covered by flock, and close() means unlock).
> 
> Now:
> 
>          your-epoll
>              |
>       library-epoll-FD
>         /        \
>  mountinfo-FD   utab.lock-inotify-FD
> 
> 
> Note that after notification it's necessary to cleanup (drain) inotify
> bufferes, so I have added mnt_monitor_event_cleanup().

Yupp, makes sense.

Lennart

-- 
Lennart Poettering, Red Hat