From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1422916AbbD2PsW (ORCPT ); Wed, 29 Apr 2015 11:48:22 -0400 Received: from mailout2.w1.samsung.com ([210.118.77.12]:43801 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753717AbbD2PsU (ORCPT ); Wed, 29 Apr 2015 11:48:20 -0400 X-AuditID: cbfec7f4-f79c56d0000012ee-87-5540fd43ee27 Message-id: <5540FD3E.9050801@samsung.com> Date: Wed, 29 Apr 2015 17:48:14 +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: <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> <5540822C.10000@samsung.com> <20150429074259.GA31089@quack.suse.cz> <20150429091303.GA4090@kroah.com> <5540BC2A.8010504@samsung.com> <20150429134505.GB15398@kroah.com> In-reply-to: <20150429134505.GB15398@kroah.com> Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsVy+t/xa7rOfx1CDS5cNrf4+qWDxeLcghmM FqcnLGKyePqpj8Vi9vRmJotbl1exWJxtesNusezBZhaLzd872CxmzrvDZrFn70kWi8u75rBZ 3Fvzn9WitecnuwOfR8vmco8Fm0o9Nq/Q8nj7MMBj06dJ7B5NZ44ye7zfd5XNo2/LKkaPMwuO sHt83iQXwBXFZZOSmpNZllqkb5fAlbF3wkmWgg1KFc+3ZDUwzpbuYuTkkBAwkdj8/SQbhC0m ceHeejBbSGApo8SOO+ldjFxA9jNGiclLl4EleAW0JPacamEBsVkEVCV67l9gB7HZBPQlXs1Y yQRiiwpESPw5vY8Vol5Q4sfke2D1IgIyEh1L9rCDDGUW2M8k8XrnLEaQhLCAp8TZDz/YILZ1 MUssetkL1sEJNHXTut9gk5gFdCT2t05jg7DlJTavecs8gVFgFpIls5CUzUJStoCReRWjaGpp ckFxUnquoV5xYm5xaV66XnJ+7iZGSFx92cG4+JjVIUYBDkYlHl4BXYdQIdbEsuLK3EOMEhzM SiK8278DhXhTEiurUovy44tKc1KLDzFKc7AoifPO3fU+REggPbEkNTs1tSC1CCbLxMEp1cAo rdOf1mUmw6tiVr5aSD39zNVZ26eJdh3WnbTiVF/JosrmxNQ/ipKTg5ukooRXO5Y7RAU+e20V +8RVSv78Whu2JxYqMe6ezapCab+i5sf3G/xcUWZ5d/Fsqe19XN75vD93Po4xVt32c1G3rGPR /kf/c9avnd7GtP4dS8yGwyXz9pYcvXqiLFSJpTgj0VCLuag4EQA20vPZpwIAAA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/29/2015 03:45 PM, Greg KH wrote: > On Wed, Apr 29, 2015 at 01:10:34PM +0200, Beata Michalska wrote: >>>>> 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. >>> >>> How are you going to show an event for a filesystem that is made up of >>> multiple block devices? >> >> AFAIK, for such filesystems there will be similar case with the anonymous >> major:minor numbers - at least the btrfs is doing so. Not sure we can >> differentiate here the actual block device. So in this case such events >> serves merely as a hint for the userspace. > > "hint" seems like this isn't really going to work well. > > Do you have userspace code that can properly map this back to the "real" > device that is causing problems? Without that, this doesn't seem all > that useful as no one would be able to use those events. I'm not sure we are on the same page here. This is about watching the file system rather than the 'real' device. Like the threshold notifications: you would like to know when you will be approaching certain level of available space for the tmpfs mounted on /tmp. You do know you are watching the /tmp and you know that the dev numbers for this are 0:20 (or so). (either through calling stat on /tmp or through reading the /proc/$$/mountinfo) With this interface you can setup threshold levels for /tmp. Then, once the limit is reached the event will be sent with those anonymous major:minor numbers. I can provide a sample code which will demonstrate how this can be achieved. > >> At this point a user might decide to run some scanning tools. > > You can't run a scanning tool on a tmpfs :) I was referring to btrfs here as a filesystem with multiple devices and its btrfs device scan :) > > So what can a user do with information about one of these "virtual" > filesystems that it can't directly see or access? > >> We might extend the scope of the >> info being sent, though I would consider this as a nice-to-have but not >> required for this initial version of notifications. The filesystems >> might also want to decide to send their own custom messages so it is >> possible for filesystems like btrfs to send more detailed information >> using the new genetlink multicast group. >>>> Or you can use /proc/self/mountinfo for the mapping. There you can see >>>> device numbers, real device names if applicable and mountpoints. This has >>>> the advantage that it works even if filesystem mountpoints change. >>> >>> Ok, then that brings up my next question, how does this handle >>> namespaces? What namespace is the event being sent in? block devices >>> aren't namespaced, but the mount points are, is that going to cause >>> problems? >>> >> >> The path should get resolved properly (as from root level). though I must >> admit I'm not sure if there will be no issues when it comes to the network >> namespaces. I'll double check it. Any hints though are more than welcomed :) > > What is "root level" here? You can mount things in different namespaces > all over the place. I was referring here to the mounts visibility and the mount propagation which on some distros is set by default with the make-shared option, so the mounts created in new namespace are visible outside of it (running cat /proc/$$/moutinfo showed the new mounts). Which got me really confused, obviously. > > This is going to get really complex very quickly :( It will/is indeed - still I believe it's worth giving it a try. I'll try to work out the namespace issue here and get back to you. BR Beata > > I still think you should tie this to an existing sysfs device, which > handles the namespace issues for you, and it also handles the fact that > userspace can properly identify the device, if at all possible. > > thanks, > > greg k-h >