From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from helmsgagent01.f-secure.com ([193.110.108.21]:52215 "EHLO helmsgagent01.f-secure.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758696AbcJQIn4 (ORCPT ); Mon, 17 Oct 2016 04:43:56 -0400 From: Marko Rauhamaa To: Amir Goldstein CC: linux-fsdevel Subject: Re: [RFC][PATCH 0/7] fanotify: add support for more events References: <87inswm9sg.fsf@drapion.f-secure.com> <87d1j3mj1k.fsf@drapion.f-secure.com> Date: Mon, 17 Oct 2016 11:43:52 +0300 In-Reply-To: (Amir Goldstein's message of "Sat, 15 Oct 2016 18:23:09 +0300") Message-ID: <87oa2je56f.fsf@drapion.f-secure.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Amir Goldstein : > 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: . > 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