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 9138BC46CD2 for ; Sat, 27 Jan 2024 18:06:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0306C6B007B; Sat, 27 Jan 2024 13:06:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F22656B007D; Sat, 27 Jan 2024 13:06:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DEA456B007E; Sat, 27 Jan 2024 13:06:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id CECAD6B007B for ; Sat, 27 Jan 2024 13:06:49 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id A998040599 for ; Sat, 27 Jan 2024 18:06:49 +0000 (UTC) X-FDA: 81725871738.11.DF050E1 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf12.hostedemail.com (Postfix) with ESMTP id 593BC40003 for ; Sat, 27 Jan 2024 18:06:46 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=YsgnMGxW; dmarc=none; spf=none (imf12.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706378808; 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=YrRyKQKMOdyRil31O+f58cq56VSF58YjdceSVVv9JJ8=; b=LOaMqVPsFQiHoU0IVQs6xAeuqOFkrCr8TXhGVTTwNmj46HqTXLIjwFCyw+9hfIU5Opn+pd D75uG3LeEyPWynSavQ8jAlF8jwwZYj/uYsfj41wOjHNUZ5M1Iv6ae0AR21uYgghtllFrrr Q0XRiasiVOQKUfD6VZ6W+lUpw53c3Us= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=YsgnMGxW; dmarc=none; spf=none (imf12.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706378808; a=rsa-sha256; cv=none; b=7JJH2ZTUxzmFF5OxSHJZoqzekmnOoAuVpnQZppQgeTVHcWwVVqRHLCdG6lW+HoGhlU6lO1 HWJK3Vfac5CV3bm2K4YJ1U40ks20yWa9Q8kfWGnq6wO3MDFNawYaASJK+ZopHW5Cv7FIhR BJOVrLRk8PchP7jCZZD2ZtsLQMfAtA0= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=YrRyKQKMOdyRil31O+f58cq56VSF58YjdceSVVv9JJ8=; b=YsgnMGxWb1w/1jTC9/BogT+wNz lzBof+rBzIFt9XPfZBbAPjoFCn4T5QnluZy9ePTc8rOllAOHhzyruwTx4H8QdUK894JdTo+3yyFpb OuJdCrcuowiZYzSPH+vIZgPQlst7Mdqsmn9eqylsxxToiH0SuJHGFYt8d2NzVHb2Y6PI7t5HBB+cj Pa+/FEFH9MXIm9quItMvSFAilpmmjUFgyoCo8UCPtyhzNfZzB8uwsxGjlp5DO8qGO/2+ytPCKCY0d Lilk1BLy+YY1YZEZ3e0Prdb51QcZJFrOmNso+44ZObwadHJ6efBt9yJ8V9xcoi9tnach6MegiZ/un OxeIBYbg==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rTn4f-0000000HZrk-1Q7z; Sat, 27 Jan 2024 18:06:37 +0000 Date: Sat, 27 Jan 2024 18:06:37 +0000 From: Matthew Wilcox To: James Bottomley 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 Subject: Re: [LSF/MM TOPIC] Making pseudo file systems inodes/dentries more like normal file systems Message-ID: 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 593BC40003 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: pb74b9r45r9z7ktarszryhhsf7sr3ozz X-HE-Tag: 1706378806-119942 X-HE-Meta: U2FsdGVkX1+tVFBX8huiHQyhEYz4bUOWwWg5/eDcsiBxEc0n283nB5JecQmiRstKYhrwTU+fp3VHppvGZmKMWrHdCImjTzHCsOyk1mtlkLqG3mDFS3i+sX7GER13G1jndujicheanjQlo0QiH+r2Z8+U8S/+xevSWtT/CSI7+5ml6ED5bIRtEbKUSs/hrZ+9Anom17OB2JCXy5EwqD5J6OEtkK4FHKqjX9+/vT2KPWfV8qND3kuk4ABPOpbXOdnhhNyTKVCruttuhAdMZS7GkFzEwFT3+4e7GyMBI/nJB9OJSSvooHvstT9YrdFn0u1FIe8nbQNmQAexn8TZHES/bOP0rZGfreOiphAHLIGkMCYGR/Lh43M7BdQU72Qyyu6moHwCRVmZuHsKXk8uzHlRnQ4c967o+TC2OcBCiL+LJmFEjAwMBHfYnmBJ3DSBX42dDpdjyRH7Qn25QlMwNPihxz9g4Y9Lz1lfm3+x40y3seMo+1Ip9AMfcM/UfTaMhDKo6zyOYJFD+ir6V5jEPjtR2oujVjjcmOdAKXMcd4PVg4WgAPJoj2Nzw8lrauzLBZ53hB45x3eEq4KExH2g2zLtKicWAx9U1pFn6niEAY4R0on/OmJ2mh2tr75U3I2/aCs1hr5oP8L0npDD7IGvhw2U2S3KdF7LxglrLDAhnMQ5NaRSFWZ4EXlGGR/8fnL+Mi459i1mE6GK6Kb+fc0D5q5tBUXFasrTIMbNSJWiTWwS9WREWfLQpyMDZnwlEJV92ENJXf7rpFQ+Rpdc+wZPuKnssUuWaX8xv/88yXiy2iIpv+IJm+qMWC/MXjZp8LAi+MEQdX/VdVIZBxTgoCrLmhG1KA== 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: 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 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.