From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966165AbbD2HDZ (ORCPT ); Wed, 29 Apr 2015 03:03:25 -0400 Received: from mailout4.w1.samsung.com ([210.118.77.14]:64436 "EHLO mailout4.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752650AbbD2HDV (ORCPT ); Wed, 29 Apr 2015 03:03:21 -0400 X-AuditID: cbfec7f4-f79c56d0000012ee-25-554082396bb8 Message-id: <5540822C.10000@samsung.com> Date: Wed, 29 Apr 2015 09:03:08 +0200 From: Beata Michalska User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-version: 1.0 To: Greg KH Cc: Jan Kara , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, hughd@google.com, lczerner@redhat.com, hch@infradead.org, linux-ext4@vger.kernel.org, linux-mm@kvack.org, kyungmin.park@samsung.com, kmpark@infradead.org Subject: Re: [RFC v2 1/4] fs: Add generic file system event notifications References: <1430135504-24334-1-git-send-email-b.michalska@samsung.com> <1430135504-24334-2-git-send-email-b.michalska@samsung.com> <20150427142421.GB21942@kroah.com> <553E50EB.3000402@samsung.com> <20150427153711.GA23428@kroah.com> <20150428135653.GD9955@quack.suse.cz> <20150428140936.GA13406@kroah.com> <553F9D56.6030301@samsung.com> <20150428173900.GA16708@kroah.com> In-reply-to: <20150428173900.GA16708@kroah.com> Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsVy+t/xq7qWTQ6hBl+vG1l8/dLBYnFuwQxG i9MTFjFZPP3Ux2Ixe3ozk8Wty6tYLM42vWG3WPZgM4vF5u8dbBYz591hs9iz9ySLxeVdc9gs 7q35z2rR2vOT3YHPo2VzuceCTaUem1doebx9GOCx6dMkdo+mM0eZPd7vu8rm0bdlFaPHmQVH 2D0+b5IL4IrisklJzcksSy3St0vgyni2VK/gqV7Fzr9LWBoYJ6h2MXJySAiYSDzonsMOYYtJ XLi3ng3EFhJYyihxZV8WhP2MUWJ+qwOIzSugIbGkcxsziM0ioCrx6OccVhCbTUBf4tWMlUwg tqhAhMSf0/tYIeoFJX5MvscCYosIyEh0LNkDtIuLg1lgP5PE652zGEESwgKeEmc//GADSQgJ /GWSuDRnPlgHJ9DUb18ngW1jFlCXmDRvEZQtL7F5zVvmCYwCs5AsmYWkbBaSsgWMzKsYRVNL kwuKk9JzDfWKE3OLS/PS9ZLzczcxQqLqyw7GxcesDjEKcDAq8fAK6DqECrEmlhVX5h5ilOBg VhLh7a0ACvGmJFZWpRblxxeV5qQWH2KU5mBREuedu+t9iJBAemJJanZqakFqEUyWiYNTqoGx 12eJVccp+7Sp67W+7b3ivv2YvXtjltfKlBZTi7/Z1j/+TFSa+CuieiPP8rXNwb272rSnPin1 3PWq2Dd+7Ym7BXvO7IrSi9DQm1CefE78cUzqzdlBMrM2HImd0DBhYuEEtRVPlOeKzy8s/ien f/alVFOOrbCmkIfIa9HFEieYW20yVh0t3WSnxFKckWioxVxUnAgAfqq4nqYCAAA= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/28/2015 07:39 PM, Greg KH wrote: > On Tue, Apr 28, 2015 at 04:46:46PM +0200, Beata Michalska wrote: >> On 04/28/2015 04:09 PM, Greg KH wrote: >>> On Tue, Apr 28, 2015 at 03:56:53PM +0200, Jan Kara wrote: >>>> On Mon 27-04-15 17:37:11, Greg KH wrote: >>>>> On Mon, Apr 27, 2015 at 05:08:27PM +0200, Beata Michalska wrote: >>>>>> On 04/27/2015 04:24 PM, Greg KH wrote: >>>>>>> On Mon, Apr 27, 2015 at 01:51:41PM +0200, Beata Michalska wrote: >>>>>>>> Introduce configurable generic interface for file >>>>>>>> system-wide event notifications, to provide file >>>>>>>> systems with a common way of reporting any potential >>>>>>>> issues as they emerge. >>>>>>>> >>>>>>>> The notifications are to be issued through generic >>>>>>>> netlink interface by newly introduced multicast group. >>>>>>>> >>>>>>>> Threshold notifications have been included, allowing >>>>>>>> triggering an event whenever the amount of free space drops >>>>>>>> below a certain level - or levels to be more precise as two >>>>>>>> of them are being supported: the lower and the upper range. >>>>>>>> The notifications work both ways: once the threshold level >>>>>>>> has been reached, an event shall be generated whenever >>>>>>>> the number of available blocks goes up again re-activating >>>>>>>> the threshold. >>>>>>>> >>>>>>>> The interface has been exposed through a vfs. Once mounted, >>>>>>>> it serves as an entry point for the set-up where one can >>>>>>>> register for particular file system events. >>>>>>>> >>>>>>>> Signed-off-by: Beata Michalska >>>>>>>> --- >>>>>>>> Documentation/filesystems/events.txt | 231 ++++++++++ >>>>>>>> fs/Makefile | 1 + >>>>>>>> fs/events/Makefile | 6 + >>>>>>>> fs/events/fs_event.c | 770 ++++++++++++++++++++++++++++++++++ >>>>>>>> fs/events/fs_event.h | 25 ++ >>>>>>>> fs/events/fs_event_netlink.c | 99 +++++ >>>>>>>> fs/namespace.c | 1 + >>>>>>>> include/linux/fs.h | 6 +- >>>>>>>> include/linux/fs_event.h | 58 +++ >>>>>>>> include/uapi/linux/fs_event.h | 54 +++ >>>>>>>> include/uapi/linux/genetlink.h | 1 + >>>>>>>> net/netlink/genetlink.c | 7 +- >>>>>>>> 12 files changed, 1257 insertions(+), 2 deletions(-) >>>>>>>> create mode 100644 Documentation/filesystems/events.txt >>>>>>>> create mode 100644 fs/events/Makefile >>>>>>>> create mode 100644 fs/events/fs_event.c >>>>>>>> create mode 100644 fs/events/fs_event.h >>>>>>>> create mode 100644 fs/events/fs_event_netlink.c >>>>>>>> create mode 100644 include/linux/fs_event.h >>>>>>>> create mode 100644 include/uapi/linux/fs_event.h >>>>>>> >>>>>>> Any reason why you just don't do uevents for the block devices today, >>>>>>> and not create a new type of netlink message and userspace tool required >>>>>>> to read these? >>>>>> >>>>>> The idea here is to have support for filesystems with no backing device as well. >>>>>> Parsing the message with libnl is really simple and requires few lines of code >>>>>> (sample application has been presented in the initial version of this RFC) >>>>> >>>>> I'm not saying it's not "simple" to parse, just that now you are doing >>>>> something that requires a different tool. If you have a block device, >>>>> you should be able to emit uevents for it, you don't need a backing >>>>> device, we handle virtual filesystems in /sys/block/ just fine :) >>>>> >>>>> People already have tools that listen to libudev for system monitoring >>>>> and management, why require them to hook up to yet-another-library? And >>>>> what is going to provide the ability for multiple userspace tools to >>>>> listen to these netlink messages in case you have more than one program >>>>> that wants to watch for these things (i.e. multiple desktop filesystem >>>>> monitoring tools, system-health checkers, etc.)? >>>> As much as I understand your concerns I'm not convinced uevent interface >>>> is a good fit. There are filesystems that don't have underlying block >>>> device - think of e.g. tmpfs or filesystems working directly on top of >>>> flash devices. These still want to send notification to userspace (one of >>>> primary motivation for this interfaces was so that tmpfs can notify about >>>> something). And creating some fake nodes in /sys/block for tmpfs and >>>> similar filesystems seems like doing more harm than good to me... >>> >>> If these are "fake" block devices, what's going to be present in the >>> block major/minor fields of the netlink message? For some reason I >>> thought it was a required field, and because of that, I thought we had a >>> "real" filesystem somewhere to refer to, otherwise how would userspace >>> know what filesystem was creating these events? >>> >>> What am I missing here? >>> >>> confused, >>> >>> greg k-h >>> >> >> For those 'fake' block devs, upon mount, get_anon_bdev will assign >> the major:minor numbers. Userspace might get those through stat. > > How can userspace do the mapping backwards from this "anonymous" > major:minor number for these types of filesystems in such a way that > they can "know" how to report the block device that is causing the > event? > > thanks, > > greg k-h > It needs to be done internally by the app but is doable. The app knows what it is watching, so it can maintain the mappings. So prior to activating the notifications it can call 'stat' on the mount point. Stat struct gives the 'st_dev' which is the device id. Same will be reported within the message payload (through major:minor numbers). So having this, the app is able to get any other information it needs. Note that the events refer to the file system as a whole and they may not necessarily have anything to do with the actual block device. BR Beata