From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id AE18AC46CD2 for ; Sat, 27 Jan 2024 20:07:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 43EC76B0081; Sat, 27 Jan 2024 15:07:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3EE5D6B0082; Sat, 27 Jan 2024 15:07:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2DD826B0083; Sat, 27 Jan 2024 15:07:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 1D0D66B0081 for ; Sat, 27 Jan 2024 15:07:12 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id EF1DAA0684 for ; Sat, 27 Jan 2024 20:07:11 +0000 (UTC) X-FDA: 81726175062.26.85063F9 Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [96.44.175.130]) by imf24.hostedemail.com (Postfix) with ESMTP id C05F8180011 for ; Sat, 27 Jan 2024 20:07:09 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=hansenpartnership.com header.s=20151216 header.b=csPcqdET; dkim=pass header.d=hansenpartnership.com header.s=20151216 header.b=pgH5Glzb; dmarc=pass (policy=none) header.from=hansenpartnership.com; spf=pass (imf24.hostedemail.com: domain of James.Bottomley@HansenPartnership.com designates 96.44.175.130 as permitted sender) smtp.mailfrom=James.Bottomley@HansenPartnership.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706386030; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=gERk24LxupyAuSv8Sp2dkqfVi8lP+NB0qAAdbYvMkBo=; b=i2bV6t6Q0AqKLchvVcIfGYQ7cm7oRQMyBQXQdSrb518nPOHpLwAq7quWiaBe2rAtbOMKpm TAtnnH7fTudga4x4+GLNMZQLdhxvZi0msmJ/a2xJPR7vXKx7lfJAuNe+sGxWEfZfkY9Mqn n8+NlDKCCaoZi1tJKH7/YTJumIJPZPY= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=hansenpartnership.com header.s=20151216 header.b=csPcqdET; dkim=pass header.d=hansenpartnership.com header.s=20151216 header.b=pgH5Glzb; dmarc=pass (policy=none) header.from=hansenpartnership.com; spf=pass (imf24.hostedemail.com: domain of James.Bottomley@HansenPartnership.com designates 96.44.175.130 as permitted sender) smtp.mailfrom=James.Bottomley@HansenPartnership.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706386030; a=rsa-sha256; cv=none; b=vMD79z+GfsL+gEbG7TwW4HTsV+J315yGqm0X9tj65EZb50nbbwZx+u5OKHehnGtc9MiW2T TLqg3BwkxVBCuApTolKEW3i0gF8bNAkSbwX4ffvTsB2Xe0356VCO6jAjezDWCUEW+qWf12 iTADWK0R9grU6v0/9trl/BZ7oBiAuLk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1706386028; bh=nWmbug6lSErFTJ7AT+oEslazCkp38lsHnZ5pb7RAh9s=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=csPcqdETWTAR4/yYxDoyWeaRke5oc7tLIHcTH0jfw3yD+P8Ll9Oj/Ld1EU7ZSx3hy OKWjJkFSrSLFaj7USme4BYIvFtqXhohg92k9ujpgNU2i+fn8+RsdFnREj3UsnPzxZb 6Y1fSizTCeDPQQKKfftL1eCSBaGbtP196dWq0VKk= Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 37EA91285EC7; Sat, 27 Jan 2024 15:07:08 -0500 (EST) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavis, port 10024) with ESMTP id dLdvEkcnvpTt; Sat, 27 Jan 2024 15:07:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1706386027; bh=nWmbug6lSErFTJ7AT+oEslazCkp38lsHnZ5pb7RAh9s=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=pgH5Glzb5fZ5o5QvmI/qk0ivVneBnmU0FnjCFIsvyJbxqn//tchnkwDYKE3uUlliv iNIshzOULslzUi0xwtYgahD/Vs243nJAttx0JN/7s/hZCKucKjTaADhdkepDb5eb/F 5d8qSr9RzgVo+PcDfFZ/FVyhhhZxIDGNF9EoUsHY= Received: from lingrow.int.hansenpartnership.com (unknown [IPv6:2601:5c4:4302:c21::c14]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id 5A0EE1281BDA; Sat, 27 Jan 2024 15:07:06 -0500 (EST) Message-ID: <07dd0096952e97cfd0d5fda5ef335c534616af2b.camel@HansenPartnership.com> Subject: Re: [LSF/MM TOPIC] Making pseudo file systems inodes/dentries more like normal file systems From: James Bottomley To: Matthew Wilcox Cc: Amir Goldstein , Steven Rostedt , Greg Kroah-Hartman , lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Christian Brauner , Al Viro , Linus Torvalds Date: Sat, 27 Jan 2024 15:07:04 -0500 In-Reply-To: References: <2024012522-shorten-deviator-9f45@gregkh> <20240125205055.2752ac1c@rorschach.local.home> <2024012528-caviar-gumming-a14b@gregkh> <20240125214007.67d45fcf@rorschach.local.home> <2024012634-rotten-conjoined-0a98@gregkh> <20240126101553.7c22b054@gandalf.local.home> <2024012600-dose-happiest-f57d@gregkh> <20240126114451.17be7e15@gandalf.local.home> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: C05F8180011 X-Stat-Signature: kjgoq4s4ioushkh7dbs6nqpg768kch43 X-HE-Tag: 1706386029-92729 X-HE-Meta: U2FsdGVkX1/m36Dhxbk48XXc4m1jIbdGLbdkDc5U6+DQOM7xzmMtyhBdQJbFvTCX3fczzlIcMZHOQlQ7bFVscB4ts6XCJLfnELhH160OOZ5cQ+pPzMJTs63PcNva7zs6y9lxc7HBohifxBOxLAUfz8TFUCkQCn9CBrZKtb1tDI6FzJpV7pH8QNkOagWjA+DXBudVQ2DahZXi/1gS76YBpxHm9PsWt6Q0epCp3H2A3Z8vqKkNAxmGhKpxfdvsJoKE/2s13paXAo3kiUW0k0UWlyTcJk75CeHwH2CS7Z2BmNmObRFmZnF2wvDBlagc3HNV6y87ilE+7RJA+du5wXNoE4NBHa2cHlNc5CMKr3Mpxfj+PwpYVtxRz5faWalvCmYOODcv0dbzWNUDTg0UXYH37BPYZsyWYOAHLPU7dDl1D0sOBzTNlh5ucpj1PrblFyhrF45pMem/nXcxJsR/q6jX/BKCB2HDXGF8qMOChtGLqTyzijT+VzVP4b+NvQJCO1dKkc/KhND7TH+8a89XaL94gR8r/lgyDW4fE3NGeqTS10pbY1VPnHfj+Pgit2qrz1Ez0tAtLEUrlARsZf6MKvjmV2c3ETggqZz4bHvQNetBe0MaK7nLFz3WfWzKjFCkyGUTEqxVRAwcp4DxuDqHtXJ/xxIkEU4r9ESS4xKx1BQJ1GW9CnpEVrrQbqDA1QZSS+vZBSkP7bBXeqbq7a2TpF3vBfc3dB/ZOct1SdnwQZSufarazbZIhOnkVAvLp+ma9HYy7gGnnzdMVgR8D8D+G26+oGOQiKBrA6rjziMIWN4ZXUXx+8NTDP4ywg/lgAjKjD5SrdcHPzrqtehOYQ22Jj5qZevvPz/ivZvEZ5IzG7tMhYXiO65yh9C3ynsnS8SuFJyhBnf0eAtOmfWIIG5uXZl9cUgxf7UWl3V1BtzaXCNLCSXUVBfGdpXA/Nyjza/41mbfXrIlA0XEbEusbE7JE7x B+MRrlc0 p5yB2dlg9EdGxiPTxhBMefiqMwwcJFjl2cW/0Dwlk7WXR58gr9ZW8ZZnjfMtywR80GSPWw6+Y/DdfGP2TmXguaEmha2ZDkSsL3to40kroylBS1vaJBjPkAtSCbXs46Txl2s+ceCPZaZW2lDEPg4FSc5e5A5T0GqtEHD0U2JRxrCt3ipaNb6TEBN6nOP4xD64z8Ju60qYQNPJR/QUn640dX6lQXgs6ya+nuXHDMqR+IY9qij3+jA3dkxPDDHU0DCftPKtmWBaQPUqHiNBOxsdXJz66wa+sdVoJ40tOqAf9mMR7FPsHAoAnA0uDTc0nRCezcR2M X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Sat, 2024-01-27 at 18:06 +0000, Matthew Wilcox wrote: > On Sat, Jan 27, 2024 at 09:59:10AM -0500, James Bottomley wrote: > > On Sat, 2024-01-27 at 12:15 +0200, Amir Goldstein wrote: > > > I would like to attend the talk about what happened since we > > > suggested that you use kernfs in LSFMM 2022 and what has happened > > > since. I am being serious, I am not being sarcastic and I am not > > > claiming that you did anything wrong :) > > > > Actually, could we do the reverse and use this session to > > investigate what's wrong with the VFS for new coders?  I had a > > somewhat similar experience when I did shiftfs way back in 2017.  > > There's a huge amount of VFS knowledge you simply can't pick up > > reading the VFS API.  The way I did it was to look at existing > > filesystems (for me overlayfs was the closes to my use case) as > > well (and of course configfs which proved to be too narrow for the > > use case).  I'd say it took a good six months before I understood > > the subtleties enough to propose a new filesystem and be capable of > > answering technical questions about it.  And remember, like Steve, > > I'm a fairly competent kernel programmer.  Six months plus of code > > reading is an enormous barrier to place in front of anyone wanting > > to do a simple filesystem, and it would be way bigger if that > > person were new(ish) to Linux. > > I'd suggest that eventfs and shiftfs are not "simple filesystems". > They're synthetic filesystems that want to do very different things > from block filesystems and network filesystems.  We have a lot of > infrastructure in place to help authors of, say, bcachefs, but not a > lot of infrastructure for synthetic filesystems (procfs, overlayfs, > sysfs, debugfs, etc). I'm not going to disagree with this at all, but I also don't think it makes the question any less valid when exposing features through the filesystem is one of our default things to do. If anything it makes it more urgent because some enterprising young thing is going create their own fantastic synthetic filesystem for something and run headlong into this. > I don't feel like I have a lot to offer in this area; it's not a > part of the VFS I'm comfortable with.  I don't really understand the > dentry/vfsmount/... interactions.  I'm more focused on the > fs/mm/block interactions.  I would probably also struggle to write a > synthetic filesystem, while I could knock up something that's a clone > of ext2 in a matter of weeks. OK, I have to confess the relationship of superblocks, struct vfsmount and struct mnt (as it then was, it's struct mnt_idmap now) to the fs tree was a huge part of that learning (as was the vagaries of the dentry cache). I'm not saying this is easy or something that interests everyone, but I think receont history demonstrates it's something we should discuss and try to do better at. James