From mboxrd@z Thu Jan 1 00:00:00 1970 From: Beata Michalska Subject: Re: [RFC v2 1/4] fs: Add generic file system event notifications Date: Tue, 28 Apr 2015 16:46:46 +0200 Message-ID: <553F9D56.6030301@samsung.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-reply-to: <20150428140936.GA13406-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Greg KH Cc: Jan Kara , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, tytso-3s7WtUTddSA@public.gmane.org, adilger.kernel-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org, hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, lczerner-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org, linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org, kmpark-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org List-Id: linux-api@vger.kernel.org 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. BR Beata From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by kanga.kvack.org (Postfix) with ESMTP id 082D06B006C for ; Tue, 28 Apr 2015 10:46:54 -0400 (EDT) Received: by pdbqa5 with SMTP id qa5so165979710pdb.1 for ; Tue, 28 Apr 2015 07:46:53 -0700 (PDT) Received: from mailout4.w1.samsung.com (mailout4.w1.samsung.com. [210.118.77.14]) by mx.google.com with ESMTPS id om4si34947155pdb.237.2015.04.28.07.46.52 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 28 Apr 2015 07:46:53 -0700 (PDT) Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout4.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0NNI00484UDZYLA0@mailout4.w1.samsung.com> for linux-mm@kvack.org; Tue, 28 Apr 2015 15:46:48 +0100 (BST) Message-id: <553F9D56.6030301@samsung.com> Date: Tue, 28 Apr 2015 16:46:46 +0200 From: Beata Michalska MIME-version: 1.0 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> In-reply-to: <20150428140936.GA13406@kroah.com> Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: 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 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. BR Beata -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030554AbbD1Oqy (ORCPT ); Tue, 28 Apr 2015 10:46:54 -0400 Received: from mailout4.w1.samsung.com ([210.118.77.14]:45379 "EHLO mailout4.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965596AbbD1Oqv (ORCPT ); Tue, 28 Apr 2015 10:46:51 -0400 X-AuditID: cbfec7f5-f794b6d000001495-85-553f9d5c5af4 Message-id: <553F9D56.6030301@samsung.com> Date: Tue, 28 Apr 2015 16:46:46 +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> In-reply-to: <20150428140936.GA13406@kroah.com> Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsVy+t/xa7oxc+1DDa4dN7T4+qWDxeLcghmM FqcnLGKyePqpj8Vi9vRmJotbl1exWJxtesNusezBZhaLzd872CxmzrvDZrFn70kWi8u75rBZ 3Fvzn9WitecnuwOfR8vmco8Fm0o9Nq/Q8nj7MMBj06dJ7B5NZ44ye7zfd5XNo2/LKkaPMwuO sHt83iQXwBXFZZOSmpNZllqkb5fAlbF50Qzmgk61ivsHTzI1MP6T7WLk5JAQMJE4/WUTK4Qt JnHh3nq2LkYuDiGBpYwSs5+/ZYJwnjFKXDr3nKWLkYODV0BLYsVCb5AGFgFViQs/djGD2GwC +hKvZqxkArFFBSIk/pzeBzaUV0BQ4sfkeywgtoiAjETHkj3sIDOZBfYzSbzeOYsRJCEs4Clx 9sMPqM07mSSOvvsKNokTaOrHuafYQGxmAXWJSfMWMUPY8hKb17xlnsAoMAvJkllIymYhKVvA yLyKUTS1NLmgOCk910ivODG3uDQvXS85P3cTIySyvu5gXHrM6hCjAAejEg9vAZd9qBBrYllx Ze4hRgkOZiURXqMJQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8M3e9DxESSE8sSc1OTS1ILYLJ MnFwSjUwbhVmub9CxHbKlD1Ma1V4i+XqHm76LRrwauHfIC973itLZjSpGS6+uoX9yBfFld8v +qT+ZZxYUf0iZ9kzV6GH0m4d5WKNy6R8H/GnNzw+9jS/oH32HYGMnDg7vcuJr9fZmH6Nm/Cc f/az/CMflJ6q7VjudF3Wa1aPYVzw0cP8LFc+tknEXc0QUmIpzkg01GIuKk4EAPRN49ioAgAA Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. BR Beata