From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp01.aussiebb.com.au (smtp01.aussiebb.com.au [121.200.0.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D86B91DDA33; Sun, 17 Nov 2024 23:29:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=121.200.0.92 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731886196; cv=none; b=a5k4gEILkc0cIVoLlCiruIqRvNzn5tsUHuOme34KieK8UHPFIum4rC9up0S3mm8YiBhU/PvWpLRHb3Y2x1OU5C4wKDJ5xrhd+JaElT2Vuyr4STKp9XQNCrv01dDtM7C8rkV2kP4Loo3d8q/5xUq5/6mysKQS+RCYRhNCAnppthg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731886196; c=relaxed/simple; bh=jIMynjpJaK/O61eRSvGhtn9jzOXXW78GlgyU9AxE0b4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ZTOGm4FIC4v3jNP+t1pSfw9QP3jbWHIQMcg/cN5s78yYr4zerLpT3JVMjsaJcS8RsXVf+zOke9IdzmPse1DXyXNEbtbcNks6OG74csGP7Rpts+RL8oJobgbGvQqwGHI6b33GF93O7hs0lY9WGJQ8R19NDbod0HNfXrng2vdZo2g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=themaw.net; spf=fail smtp.mailfrom=themaw.net; arc=none smtp.client-ip=121.200.0.92 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=themaw.net Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=themaw.net Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp01.aussiebb.com.au (Postfix) with ESMTP id 605B7100814; Mon, 18 Nov 2024 10:29:46 +1100 (AEDT) X-Virus-Scanned: Debian amavisd-new at smtp01.aussiebb.com.au Received: from smtp01.aussiebb.com.au ([127.0.0.1]) by localhost (smtp01.aussiebb.com.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSGkpr7bSMwc; Mon, 18 Nov 2024 10:29:46 +1100 (AEDT) Received: by smtp01.aussiebb.com.au (Postfix, from userid 116) id 503DA100723; Mon, 18 Nov 2024 10:29:46 +1100 (AEDT) X-Spam-Level: Received: from [192.168.50.229] (159-196-82-144.9fc452.per.static.aussiebb.net [159.196.82.144]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: ian146@aussiebb.com.au) by smtp01.aussiebb.com.au (Postfix) with ESMTPSA id C06851006EE; Mon, 18 Nov 2024 10:29:43 +1100 (AEDT) Message-ID: Date: Mon, 18 Nov 2024 07:29:42 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 0/3] fs: allow statmount to fetch the fs_subtype and sb_source To: Jan Kara Cc: Jeff Layton , Karel Zak , Christian Brauner , Miklos Szeredi , Josef Bacik , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Alexander Viro References: <20241111-statmount-v4-0-2eaf35d07a80@kernel.org> <20241112-antiseptisch-kinowelt-6634948a413e@brauner> <63f3aa4b3d69b33f1193f4740f655ce6dae06870.camel@kernel.org> <20241113151848.hta3zax57z7lprxg@quack3> <83b4c065-8cb4-4851-a557-aa47b7d03b6f@themaw.net> <20241114115652.so2dkvhaahl2ygvl@quack3> Content-Language: en-US From: Ian Kent Autocrypt: addr=raven@themaw.net; keydata= xsFNBE6c/ycBEADdYbAI5BKjE+yw+dOE+xucCEYiGyRhOI9JiZLUBh+PDz8cDnNxcCspH44o E7oTH0XPn9f7Zh0TkXWA8G6BZVCNifG7mM9K8Ecp3NheQYCk488ucSV/dz6DJ8BqX4psd4TI gpcs2iDQlg5CmuXDhc5z1ztNubv8hElSlFX/4l/U18OfrdTbbcjF/fivBkzkVobtltiL+msN bDq5S0K2KOxRxuXGaDShvfbz6DnajoVLEkNgEnGpSLxQNlJXdQBTE509MA30Q2aGk6oqHBQv zxjVyOu+WLGPSj7hF8SdYOjizVKIARGJzDy8qT4v/TLdVqPa2d0rx7DFvBRzOqYQL13/Zvie kuGbj3XvFibVt2ecS87WCJ/nlQxCa0KjGy0eb3i4XObtcU23fnd0ieZsQs4uDhZgzYB8LNud WXx9/Q0qsWfvZw7hEdPdPRBmwRmt2O1fbfk5CQN1EtNgS372PbOjQHaIV6n+QQP2ELIa3X5Z RnyaXyzwaCt6ETUHTslEaR9nOG6N3sIohIwlIywGK6WQmRBPyz5X1oF2Ld9E0crlaZYFPMRH hQtFxdycIBpTlc59g7uIXzwRx65HJcyBflj72YoTzwchN6Wf2rKq9xmtkV2Eihwo8WH3XkL9 cjVKjg8rKRmqIMSRCpqFBWJpT1FzecQ8EMV0fk18Q5MLj441yQARAQABzRtJYW4gS2VudCA8 cmF2ZW5AdGhlbWF3Lm5ldD7CwXsEEwECACUCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheA BQJOnjOcAhkBAAoJEOdnc4D1T9iphrYQALHK3J5rjzy4qPiLJ0EE9eJkyV1rqtzct5Ah9pu6 LSkqxgQCfN3NmKOoj+TpbXGagg28qTGjkFvJSlpNY7zAj+fA11UVCxERgQBOJcPrbgaeYZua E4ST+w/inOdatNZRnNWGugqvez80QGuxFRQl1ttMaky7VxgwNTXcFNjClW3ifdD75gHlrU0V ZUULa1a0UVip0rNc7mFUKxhEUk+8NhowRZUk0nt1JUwezlyIYPysaN7ToVeYE4W0VgpWczmA tHtkRGIAgwL7DCNNJ6a+H50FEsyixmyr/pMuNswWbr3+d2MiJ1IYreZLhkGfNq9nG/+YK/0L Q2/OkIsz8bOrkYLTw8WwzfTz2RXV1N2NtsMKB/APMcuuodkSI5bzzgyu1cDrGLz43faFFmB9 xAmKjibRLk6ChbmrZhuCYL0nn+RkL036jMLw5F1xiu2ltEgK2/gNJhm29iBhvScUKOqUnbPw DSMZ2NipMqj7Xy3hjw1CStEy3pCXp8/muaB8KRnf92VvjO79VEls29KuX6rz32bcBM4qxsVn cOqyghSE69H3q4SY7EbhdIfacUSEUV+m/pZK5gnJIl6n1Rh6u0MFXWttvu0j9JEl92Ayj8u8 J/tYvFMpag3nTeC3I+arPSKpeWDX08oisrEp0Yw15r+6jbPjZNz7LvrYZ2fa3Am6KRn0zsFN BE6c/ycBEADZzcb88XlSiooYoEt3vuGkYoSkz7potX864MSNGekek1cwUrXeUdHUlw5zwPoC 4H5JF7D8q7lYoelBYJ+Mf0vdLzJLbbEtN5+v+s2UEbkDlnUQS1yRo1LxyNhJiXsQVr7WVA/c 8qcDWUYX7q/4Ckg77UO4l/eHCWNnHu7GkvKLVEgRjKPKroIEnjI0HMK3f6ABDReoc741RF5X X3qwmCgKZx0AkLjObXE3W769dtbNbWmW0lgFKe6dxlYrlZbq25Aubhcu2qTdQ/okx6uQ41+v QDxgYtocsT/CG1u0PpbtMeIm3mVQRXmjDFKjKAx9WOX/BHpk7VEtsNQUEp1lZo6hH7jeo5me CYFzgIbXdsMA9TjpzPpiWK9GetbD5KhnDId4ANMrWPNuGC/uPHDjtEJyf0cwknsRFLhL4/NJ KvqAuiXQ57x6qxrkuuinBQ3S9RR3JY7R7c3rqpWyaTuNNGPkIrRNyePky/ZTgTMA5of8Wioy z06XNhr6mG5xT+MHztKAQddV3xFy9f3Jrvtd6UvFbQPwG7Lv+/UztY5vPAzp7aJGz2pDbb0Q BC9u1mrHICB4awPlja/ljn+uuIb8Ow3jSy+Sx58VFEK7ctIOULdmnHXMFEihnOZO3NlNa6q+ XZOK7J00Ne6y0IBAaNTM+xMF+JRc7Gx6bChES9vxMyMbXwARAQABwsFfBBgBAgAJBQJOnP8n AhsMAAoJEOdnc4D1T9iphf4QAJuR1jVyLLSkBDOPCa3ejvEqp4H5QUogl1ASkEboMiWcQJQd LaH6zHNySMnsN6g/UVhuviANBxtW2DFfANPiydox85CdH71gLkcOE1J7J6Fnxgjpc1Dq5kxh imBSqa2hlsKUt3MLXbjEYL5OTSV2RtNP04KwlGS/xMfNwQf2O2aJoC4mSs4OeZwsHJFVF8rK XDvL/NzMCnysWCwjVIDhHBBIOC3mecYtXrasv9nl77LgffyyaAAQZz7yZcvn8puj9jH9h+mr L02W+gd+Sh6Grvo5Kk4ngzfT/FtscVGv9zFWxfyoQHRyuhk0SOsoTNYN8XIWhosp9GViyDtE FXmrhiazz7XHc32u+o9+WugpTBZktYpORxLVwf9h1PY7CPDNX4EaIO64oyy9O3/huhOTOGha nVvqlYHyEYCFY7pIfaSNhgZs2aV0oP13XV6PGb5xir5ah+NW9gQk/obnvY5TAVtgTjAte5tZ +coCSBkOU1xMiW5Td7QwkNmtXKHyEF6dxCAMK1KHIqxrBaZO27PEDSHaIPHePi7y4KKq9C9U 8k5V5dFA0mqH/st9Sw6tFbqPkqjvvMLETDPVxOzinpU2VBGhce4wufSIoVLOjQnbIo1FIqWg Dx24eHv235mnNuGHrG+EapIh7g/67K0uAzwp17eyUYlE5BMcwRlaHMuKTil6 In-Reply-To: <20241114115652.so2dkvhaahl2ygvl@quack3> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 14/11/24 19:56, Jan Kara wrote: > On Thu 14-11-24 09:45:23, Ian Kent wrote: >> On 13/11/24 23:18, Jan Kara wrote: >>> On Wed 13-11-24 08:45:06, Jeff Layton wrote: >>>> On Wed, 2024-11-13 at 12:27 +0100, Karel Zak wrote: >>>>> On Tue, Nov 12, 2024 at 02:39:21PM GMT, Christian Brauner wrote: >>>>> Next on the wish list is a notification (a file descriptor that can be >>>>> used in epoll) that returns a 64-bit ID when there is a change in the >>>>> mount node. This will enable us to enhance systemd so that it does not >>>>> have to read the entire mount table after every change. >>>>> >>>> New fanotify events for mount table changes, perhaps? >>> Now that I'm looking at it I'm not sure fanotify is a great fit for this >>> usecase. A lot of fanotify functionality does not really work for virtual >>> filesystems such as proc and hence we generally try to discourage use of >>> fanotify for them. So just supporting one type of event (like FAN_MODIFY) >>> on one file inside proc looks as rather inconsistent interface. But I >>> vaguely remember we were discussing some kind of mount event, weren't we? >>> Or was that for something else? >> I still need to have a look at the existing notifications sub-systems but, >> tbh, I also don't think they offer the needed functionality. >> >> The thing that was most useful with David's notifications when I was trying >> to improve the mounts handling was the queuing interface. It allowed me to >> batch notifications up to around a couple of hundred and grab them in one go >> for processing. This significantly lowered the overhead of rapid fire event >> processing. The ability to go directly to an individual mount and get it's >> information only got about half the improvement I saw, the rest come from >> the notifications improvement. > Well, if we implemented the mount notification events in fanotify, then the > mount events get queued in the notification group queue and you can process > the whole batch of events in one go if you want. So I don't see batching as > an issue. What I'm more worried about is that watching the whole system > for new mounts is going to be somewhat cumbersome when all you can do is to > watch new mounts attached under an existing mount / filesystem. But, for mounts/unounts for example, isn't it the act of performing the mount/unmount that triggers the notification if the path in within a file system that's marked to report such events? Ian