Re: [RFC][PATCH 0/7] fanotify: add support for more events

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Amir Goldstein <amir73il@xxxxxxxxx>:
> Let me rephrse my question - please argue why monitoring a file system
> instead of a mount point is important for your use case and more impotantly,
> please argue why you cannot achive the same result by monitoring all the
> relevant mount points from user space.

We are already doing that and missing fanotify events that are shrouded
by namespaces. Namespaces are popular through the use of containers, but
not only that. Distros are using namespaces to protect the private files
of services:

   <URL: http://fedoraproject.org/wiki/Features/ServicesPrivateTmp>

   <URL: https://access.redhat.com/blogs/766093/posts/1976243>.

> For example, the argument I used against the legacy recursive intotify
> watch of all directories in the treee is the poor ability to scale
> well over millions of directories.

Sure, that would be untenable. I'd argue the namespace issue is at least
equally tough because you'd have to keep monitoring namespaces deep
under the /proc hierarchy where processes come and go, there is no
epollable notification scheme available (to my knowledge) and race
conditions are inevitable. It would be virtually impossible for a
top-level fanotify monitor to keep track of what is going on.


Marko
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux