From: Steven Whitehouse <firstname.lastname@example.org> To: Linus Torvalds <email@example.com> Cc: David Howells <firstname.lastname@example.org>, Miklos Szeredi <email@example.com>, linux-fsdevel <firstname.lastname@example.org>, Al Viro <email@example.com>, Karel Zak <firstname.lastname@example.org>, Jeff Layton <email@example.com>, Miklos Szeredi <firstname.lastname@example.org>, Nicolas Dichtel <email@example.com>, Christian Brauner <firstname.lastname@example.org>, Lennart Poettering <email@example.com>, Linux API <firstname.lastname@example.org>, Ian Kent <email@example.com>, LSM <firstname.lastname@example.org>, Linux Kernel Mailing List <email@example.com> Subject: Re: file metadata via fs API Date: Mon, 17 Aug 2020 12:32:52 +0100 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <CAHk-=wgz5H-xYG4bOrHaEtY7rvFA1_6+mTSpjrgK8OsNbfF+Pw@mail.gmail.com> Hi, On 12/08/2020 20:50, Linus Torvalds wrote: > On Wed, Aug 12, 2020 at 12:34 PM Steven Whitehouse <email@example.com> wrote: >> The point of this is to give us the ability to monitor mounts from >> userspace. > We haven't had that before, I don't see why it's suddenly such a big deal. > > The notification side I understand. Polling /proc files is not the answer. > > But the whole "let's design this crazy subsystem for it" seems way > overkill. I don't see anybody caring that deeply. > > It really smells like "do it because we can, not because we must". > > Who the hell cares about monitoring mounts at a kHz frequencies? If > this is for MIS use, you want a nice GUI and not wasting CPU time > polling. > > I'm starting to ignore the pull requests from David Howells, because > by now they have had the same pattern for a couple of years now: > esoteric new interfaces that seem overdesigned for corner-cases that > I'm not seeing people clamoring for. > > I need (a) proof this is actualyl something real users care about and > (b) way more open discussion and implementation from multiple parties. > > Because right now it looks like a small in-cabal of a couple of people > who have wild ideas but I'm not seeing the wider use of it. > > Convince me otherwise. AGAIN. This is the exact same issue I had with > the notification queues that I really wanted actual use-cases for, and > feedback from actual outside users. > > I really think this is engineering for its own sake, rather than > responding to actual user concerns. > > Linus > I've been hesitant to reply to this immediately, because I can see that somehow there is a significant disconnect between what you expect to happen, and what has actually happened in this case. Have pondered this for a few days, I hope that the best way forward might be to explore where the issues are, with the intention of avoiding a repeat in the future. Sometimes email is a difficult medium for these kinds of communication, and face to face is better, but with the lack of conferences/travel at the moment, that option is not open in the near future. The whole plan here, leading towards the ability to get a "dump plus updates" view of mounts in the kernel has been evolving over time. It has been discussed at LSF over a number of years  and in fact the new mount API which was merged recently - I wonder if this is what you are referring to above as: > I'm starting to ignore the pull requests from David Howells, because > by now they have had the same pattern for a couple of years now was originally proposed by Al, and also worked on by Miklos in 2017 and others. Community discussion resulted in that becoming a prerequisite for the later notifications/fsinfo work. This was one of the main reasons that David picked it up to work on, but not the only reason. That did also appear to be logical, in that cleaning up the way in which arguments were handled during mount would make it much easier to create future generic code to handle them. That said, the overall aim here is to solve the problem and if there are better solutions available then I'm sure that everyone is very open to those. I agree very much that monitoring at kHz frequencies is not useful, but at the same time, there are cases which can generate large amounts of mount changes in a very short time period. We want to be reasonably efficient, but not to over-optimise, and sometimes that is a fine line. We also don't want to block mounts if the notifications queue fills up, so some kind of resync operation would be required in the queue overflows. The notifications and fsinfo were designed very much as two sides of the same coin, but submitted separately for ease of review more than anything else. You recently requested some details of real users for the notifications, and (I assumed) by extension fsinfo too. Ian wrote these emails  in direct response to your request. That is what we thought you were looking for, so if that isn't not quite what you meant, perhaps you could clarify a bit more. Again, apologies if we've misinterpreted what you were asking for. You also mention "...it looks like a small in-cabal of a couple of people..." and I hope that it doesn't look that way, it is certainly not our intention. There have been a fair number of people involved, and we've done our best to ensure that the development is guided by the potential users, such as autofs, AFS and systemd. If there are others out there with use cases, and particularly so if the use case is a GUI file manager type application who'd like to get involved, then please do. We definitely want to see involvement from end users, since there is no point in spending a large effort creating something that is then never used. As you pointed that out above, this kind of application was very much part of the original motivation, but we had started with the other users since there were clearly defined use cases that could demonstrate significant performance gains in those cases. So hopefully that helps to give a bit more background about where we are and how we got here. Where we go next will no doubt depend on the outcome of the current discussions, and any guidance you can give around how we should have better approached this would be very helpful at this stage, Steve.  https://lwn.net/Articles/718803/  https://lwn.net/Articles/718638/  https://lwn.net/Articles/753473/  https://lkml.org/lkml/2020/6/2/1182  https://firstname.lastname@example.org/
next prev parent reply other threads:[~2020-08-17 11:33 UTC|newest] Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-08-03 15:27 [GIT PULL] Mount notifications David Howells 2020-08-03 15:49 ` [GIT PULL] Filesystem Information David Howells 2020-08-03 16:42 ` Miklos Szeredi 2020-08-04 2:15 ` Ian Kent 2020-08-04 14:36 ` Miklos Szeredi 2020-08-05 1:33 ` Ian Kent 2020-08-05 8:00 ` Miklos Szeredi 2020-08-05 11:13 ` Ian Kent 2020-08-05 8:24 ` file metadata via fs API (was: [GIT PULL] Filesystem Information) Miklos Szeredi 2020-08-11 13:54 ` Miklos Szeredi 2020-08-11 14:08 ` Al Viro 2020-08-11 14:22 ` Miklos Szeredi 2020-08-11 14:31 ` Al Viro [not found] ` <CAAgocE07=vVKpQhG+rjEGO=NEBKZ02gjg4TRPxECAc+RKrzn=Q@mail.gmail.com> 2020-08-11 14:36 ` Al Viro 2020-08-11 14:36 ` Miklos Szeredi 2020-08-11 14:42 ` Al Viro 2020-08-11 14:47 ` Miklos Szeredi 2020-08-11 15:20 ` Linus Torvalds 2020-08-11 15:30 ` Miklos Szeredi 2020-08-11 16:05 ` Linus Torvalds 2020-08-11 18:49 ` Miklos Szeredi 2020-08-11 19:31 ` Lennart Poettering 2020-08-11 19:50 ` Christian Brauner 2020-08-11 19:39 ` Christian Brauner 2020-08-12 0:53 ` Ian Kent 2020-08-11 15:39 ` Andy Lutomirski 2020-08-11 16:17 ` Casey Schaufler 2020-08-11 16:30 ` Linus Torvalds 2020-08-11 20:28 ` Miklos Szeredi 2020-08-11 20:36 ` Jann Horn 2020-08-11 20:56 ` Miklos Szeredi 2020-08-11 21:17 ` Andy Lutomirski 2020-08-11 21:18 ` Linus Torvalds 2020-08-12 7:23 ` Miklos Szeredi 2020-08-12 14:39 ` Al Viro 2020-08-12 14:46 ` Miklos Szeredi 2020-08-12 15:08 ` Al Viro 2020-08-12 15:13 ` Miklos Szeredi 2020-08-12 16:33 ` Al Viro 2020-08-12 17:16 ` Miklos Szeredi 2020-08-12 17:39 ` Al Viro 2020-08-12 18:33 ` Al Viro 2020-08-12 21:30 ` Al Viro 2020-08-18 9:41 ` Miklos Szeredi 2020-08-18 9:30 ` Miklos Szeredi 2020-08-12 15:22 ` David Howells 2020-08-11 21:20 ` Al Viro 2020-08-11 21:35 ` Casey Schaufler 2020-08-11 16:05 ` Al Viro 2020-08-11 16:09 ` Linus Torvalds 2020-08-11 16:39 ` Al Viro 2020-08-12 10:14 ` Karel Zak 2020-08-12 13:09 ` Miklos Szeredi 2020-08-12 13:33 ` David Howells 2020-08-12 13:54 ` Miklos Szeredi 2020-08-12 0:05 ` David Howells 2020-08-12 7:55 ` Miklos Szeredi 2020-08-12 8:29 ` David Howells 2020-08-12 8:37 ` Miklos Szeredi 2020-08-12 9:43 ` file metadata via fs API Steven Whitehouse 2020-08-12 10:04 ` Miklos Szeredi 2020-08-12 11:28 ` Karel Zak 2020-08-12 12:43 ` Miklos Szeredi 2020-08-13 8:52 ` Karel Zak 2020-08-12 13:06 ` David Howells 2020-08-13 1:01 ` Ian Kent 2020-08-12 18:18 ` file metadata via fs API (was: [GIT PULL] Filesystem Information) Linus Torvalds 2020-08-12 19:34 ` file metadata via fs API Steven Whitehouse 2020-08-12 19:50 ` Linus Torvalds 2020-08-13 3:44 ` Ian Kent 2020-08-13 10:36 ` Karel Zak 2020-08-14 7:58 ` Lennart Poettering 2020-08-17 11:32 ` Steven Whitehouse [this message] 2020-08-17 17:15 ` Linus Torvalds 2020-08-17 22:44 ` Linus Torvalds 2020-08-18 12:50 ` Miklos Szeredi 2020-08-18 18:51 ` Linus Torvalds 2020-08-18 20:18 ` Miklos Szeredi 2020-08-18 20:53 ` Linus Torvalds 2020-08-21 13:17 ` Miklos Szeredi 2020-08-19 2:29 ` Al Viro 2020-08-13 3:53 ` file metadata via fs API (was: [GIT PULL] Filesystem Information) Jeffrey E Altman 2020-08-14 17:05 ` Linus Torvalds 2020-08-18 15:01 ` Jeffrey E Altman 2020-08-14 8:06 ` Lennart Poettering 2020-08-12 13:54 ` David Howells 2020-08-12 14:10 ` Miklos Szeredi 2020-08-12 14:23 ` David Howells 2020-08-03 22:48 ` [GIT PULL] Mount notifications Ian Kent
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: file metadata via fs API' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).