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 177C7C47DDB for ; Mon, 29 Jan 2024 15:08:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A45866B0099; Mon, 29 Jan 2024 10:08:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9F59B6B009F; Mon, 29 Jan 2024 10:08:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8BD306B00A5; Mon, 29 Jan 2024 10:08:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 7DBE46B0099 for ; Mon, 29 Jan 2024 10:08:43 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1D3FA120A28 for ; Mon, 29 Jan 2024 15:08:43 +0000 (UTC) X-FDA: 81732680526.25.261AA67 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf16.hostedemail.com (Postfix) with ESMTP id 10E49180036 for ; Mon, 29 Jan 2024 15:08:40 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=bfd48Iqg; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf16.hostedemail.com: domain of brauner@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=brauner@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706540921; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=eKBQyItpu2rvoBevXXZ55stq9+vsTiocATk2167E3a8=; b=lQLolOXyJ47/ddbvlxi+ffN2WGRA64rCm5dF7ftPn6hpMvrkdDZIcMUG/Y9JqXBg5gIWTK BWxhrITdt2wyeWYfATPcL1N7WkJVzEZzV3nyF4sbywx/dOmZy9XjvWDCORwBk9+Bq6rnT+ irIEEVA6Mx7Bg1F3/eJCfcmkZp8Dy4U= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=bfd48Iqg; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf16.hostedemail.com: domain of brauner@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=brauner@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706540921; a=rsa-sha256; cv=none; b=XZ9RIpKH52i6p/Tg0+Vb2Fgh8aNTPASsE9pAjbDxQTeOZGCzM50ltK7rLMenpSZWN4zbAU Df33cUOatu8jtSMfn9BEgwTw7V6H9zCkbsyEisKyPS0Gwa8VHWFPA1urtFGGyjNIK5muR5 VbxSVjQEmZRZQfsXon6k22KJlJ+I3RM= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id E43EE61FF8; Mon, 29 Jan 2024 15:08:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6FB94C433F1; Mon, 29 Jan 2024 15:08:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1706540919; bh=7FXRGCG/f/woumMxDrjET2pGT5bSeHmMVwMIDmuhlBA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bfd48Iqg7JltRCl1j/I5FJ9W8hfnKtXc/vtUpQ2WtZncFrus7U2XgvZJmoUzkcy45 3PiPEBAV6eXKMzgDIyHB2shuixeZsMv0KHjJ0NA6WKI8EiyQ57wc9Y4kYzZCgbjmR+ 446imBcz8VvO2HbzpY/GFke5wV0Jv5H1PjXREVJbtKeKn6iiAyPiCoGwpEPCV0iSRz f3M0ImMXNZMP0LhwnGDMPKN+qXo8VRZ/vxaha1RDYRDAGiNXnZt4IBD+XVzM96ekpx SwbISnKdFj1VPgQ6JQcC19TtAlzvvNrhA22byp1/2XdrG/1Z4wUwCbn2Bf9HjsXbI9 OYGyZTcD2v8MA== Date: Mon, 29 Jan 2024 16:08:33 +0100 From: Christian Brauner To: Linus Torvalds Cc: Matthew Wilcox , James Bottomley , Amir Goldstein , Steven Rostedt , Greg Kroah-Hartman , lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Al Viro Subject: Re: [LSF/MM TOPIC] Making pseudo file systems inodes/dentries more like normal file systems Message-ID: <20240129-umrechnen-kaiman-cb591bc22fc5@brauner> References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 10E49180036 X-Stat-Signature: q619y75p388ad5pf3rgyzqmk5iesau1e X-HE-Tag: 1706540920-941181 X-HE-Meta: U2FsdGVkX1+hfhbxbZJQ4oBP8YvOURyIKm+IWVVDSOMKJnb8SZflbEpK/vgp5cre8Qt1IQlcXZnW1kX8prhatJ3KVFmHWvVrR+29FGbbOi+d7il2NwFj9vdS0dv2VQc1pafkqpMc3ql5BChTdhMuN3YfCxVCLzDIcMRIjZ8yevKeDemIEYBQTgHBW36TtFEeQHm6YVcybMCrkE/6DhfqzrX//289cTGQavgQBuY67AqbX08+VtVVrlufTxOpWO2KwygITyA4hrz5EVLYc/o2hGJn4BfZe4A5qi7p+PpnTWPyG8cxawXROq2C8tRZR/2xjmE3QkaH0srDk0ZFEVn99rUFxhRaxWdKEIhb9HbHYeDnO0abGeZXWEewqOHlKOkWOxA/kEsHOq0AiZqrdorYDful0Vf21+BxS/wCubOjLG/NHoARS5FSOxrUt3IkeLhtUdm17y0ipa+I4slIrD3jdksn4Y5Ab3iV7Fu2jkg8qWJrtl1KXmkOeyctPb69pa7tlUAYje5HZ9mQ0RZA5/Sibo8ocJFo7iGKfKeMKRpIsD0pQMlueqJoFaBGP6iBmvj8FyQnFCvnwnPZMH0dU+GGXwgadPbMCJ+wNwCB+ZRZhK/LWay6HayHcN+0ggFVM+ykS43oeGsAvwm8N+u3hZDtw1Pa/0GkFeHveNu4JZvkl5kB94IIl+9H3XzOujldbYgWKFGYq8NHvrFcMbX/Ug0YXEckEsf4YhJaiMZpFrPDyzKZwyRwIY73j0iHYOpaQ4eijIk+FRmuf2VH0Tr1oYMmOSp1IjPZUwYvg3OUY/wuuM5hsJfarcmo39TjLLvVrTkmePlgSGyQAXLqN6RtRk4OFDgm8/z/N5rwLfMCQzDoWMSLPwJte129xOIQ+rpEEDuw+oYPFcuCpmzm5aN88++mFlmNOLzFXgKKzGsOkiIYdLYI0OP4cu/YaSEXP28yn0g2bqV/OQg1ADGh8xhTxfC jx1SEvVW BLBFMBCCwublgQQbluNG5ruJV+MKaVlYsosM9w6qYdA/RrVAGhVJvgQsnlwg+OTq/AWoGYDwKAgK7X8ElHuvFfgeQAosxBcX5Fo70FbkRy2KMTCrkzV7KiPezkM2NXJZRo5MICdAVVSE9GdM+FiSMU5PqDpIU/CHN93nGtoPicDiUsvNNZxEk6lYkD/1JVvUrH4R0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: > But no. You should *not* look at a virtual filesystem as a guide how > to write a filesystem, or how to use the VFS. Look at a real FS. A > simple one, and preferably one that is built from the ground up to > look like a POSIX one, so that you don't end up getting confused by > all the nasty hacks to make it all look ok. > > IOW, while FAT is a simple filesystem, don't look at that one, just > because then you end up with all the complications that come from > decades of non-UNIX filesystem history. > > I'd say "look at minix or sysv filesystems", except those may be > simple but they also end up being so legacy that they aren't good > examples. You shouldn't use buffer-heads for anything new. But they > are still probably good examples for one thing: if you want to > understand the real power of dentries, look at either of the minix or > sysv 'namei.c' files. Just *look* at how simple they are. Ignore the > internal implementation of how a directory entry is then looked up on > disk - because that's obviously filesystem-specific - and instead just > look at the interface. I agree and I have to say I'm getting annoyed with this thread. And I want to fundamentally oppose the notion that it's too difficult to write a virtual filesystem. Just one look at how many virtual filesystems we already have and how many are proposed. Recent example is that KVM wanted to implement restricted memory as a stacking layer on top of tmpfs which I luckily caught early and told them not to do. If at all a surprising amount of people that have nothing to do with filesystems manage to write filesystem drivers quickly and propose them upstream. And I hope people take a couple of months to write a decently sized/complex (virtual) filesystem. And specifically for virtual filesystems they often aren't alike at all. And that's got nothing to do with the VFS abstractions. It's simply because a virtual filesystem is often used for purposes when developers think that they want a filesystem like userspace interface but don't want all of the actual filesystem semantics that come with it. So they all differ from each other and what functionality they actually implement. And I somewhat oppose the notion that the VFS isn't documented. We do have extensive documentation for locking rules, a constantly updated changelog with fundamental changes to all VFS APIs and expectations around it. Including very intricate details for the reader that really needs to know everything. I wrote a whole document just on permission checking and idmappings when we added that to the VFS. Both implementation and theoretical background. And stuff like overlayfs or shiftfs are completely separate stories because they're even more special as they're (virtual) stacking filesystems that challenge the VFS in way more radical ways than regular virtual filesystems. And I think (Amir may forgive me) that stacking filesystems are generally an absolutely terrible idea as they complicate the VFS massively and put us through an insane amount of pain. One just needs to look at how much additional VFS machinery we have because of that and how complicated our callchains can become because of that. It's just not correct to even compare them to a boring virtual filesystem like binderfs or bpffs.