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 F3CD1C47258 for ; Fri, 26 Jan 2024 03:15:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 62DA96B007D; Thu, 25 Jan 2024 22:15:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5B64E6B007E; Thu, 25 Jan 2024 22:15:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 47E0F6B0080; Thu, 25 Jan 2024 22:15:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 33F2C6B007D for ; Thu, 25 Jan 2024 22:15:21 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id CB4D5C0E98 for ; Fri, 26 Jan 2024 02:40:12 +0000 (UTC) X-FDA: 81719907864.28.E919C81 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf25.hostedemail.com (Postfix) with ESMTP id 2E5EFA0004 for ; Fri, 26 Jan 2024 02:40:10 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of "SRS0=9W0d=JE=goodmis.org=rostedt@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=9W0d=JE=goodmis.org=rostedt@kernel.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706236811; 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; bh=7E2HWfBk8Bjf4R8qASXDArKRQi7gUFgANv5p8EZ71DM=; b=m4bp7FA2RsEYLkZwsD9TN/N4KtMdX2Buleblm584XkzVTPh5LZteX0iHZrojtGkGmeWkwE 9vwe4qwlxsFwTFTEM/3bLKI108HBDYAzQA9dbV6Av17yRevTcdpJYMxnfi9TgcZ1FB+Wrl Q9SAhchcbW8ZOK7QOMgaQQSFURXGvBk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706236811; a=rsa-sha256; cv=none; b=6n3CNst4D04LkqslKs/NL4GmWn3FzOGjgl5g0zuA1qEBWUH316Ukw491fMpmkvIAewHcMx 8cjfz8ZgwWaHbz6Z62XqplLDGzZPpMu4Ej3MSguBuNdlD1CflAOIpgOfWsqFQUca05fRnv +CmFURH15v+OeY947MWbmAVD8EPqukU= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of "SRS0=9W0d=JE=goodmis.org=rostedt@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=9W0d=JE=goodmis.org=rostedt@kernel.org"; dmarc=none Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 2BA8062392; Fri, 26 Jan 2024 02:40:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC0CDC433F1; Fri, 26 Jan 2024 02:40:08 +0000 (UTC) Date: Thu, 25 Jan 2024 21:40:07 -0500 From: Steven Rostedt To: Greg Kroah-Hartman Cc: 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: <20240125214007.67d45fcf@rorschach.local.home> In-Reply-To: <2024012528-caviar-gumming-a14b@gregkh> References: <20240125104822.04a5ad44@gandalf.local.home> <2024012522-shorten-deviator-9f45@gregkh> <20240125205055.2752ac1c@rorschach.local.home> <2024012528-caviar-gumming-a14b@gregkh> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 2E5EFA0004 X-Rspam-User: X-Stat-Signature: dchrdcdx6yhdrbsboyumubt8dxmpnran X-Rspamd-Server: rspam03 X-HE-Tag: 1706236810-912651 X-HE-Meta: U2FsdGVkX1/Vf1DjwgMkCdN3AggwKLodTQ1Cfcoyo+HLfVg3deVCDZZsBmRbiL3vWBT9S/wfI+o3FwpPTbYqHWeQEb7GiH5/i/oGcoYzmMV+QAPJ/BKXUDqAapjk5NbE2dnsbDescQ8ReuKd5Ztf3bsF7RoYffQHGBvQyZ3AFhEuicwFqnhrL2QJxLbbTjS5D49XQp61TMQk32TNpHfxf9DBIntFO/scHHQgLV0+xV6a0pC26TbHw8PTcgqqoduj6PmuVa90/2otK1GDqWmQCgMgXVaWyeLBRM8In3yTxIh+l5I8GjME0JSsMpPasou1US35amj07M6KJpCiNahbn36z0WcJ4VM/EXt2kznS15swDUUKyiqSCH3tNJdg3YPWWfANONAJDn0p2vWbfBzfBd/ybYJzC8Z46R5zOBSH+DJr38QFhI0PcWt5tIuPxmkqpPZkcjmkY9s/NvX21ILJkPfZeWUBDq/g5n9RlTngYPHwJqe7tHudDhzxxOVc961qlmnks040bxzKdBqsh4y5hunqkJht5H3BBpLpjMY604Zco4ULp6IOIOPSKZFVtfbcqXYS1brJvegwryl5KMuxLfGX1Noq4pu7z4QObTMo3LOOC92fgXA8cfdrvQy63zqtohjz+MHzx3TktQ0t+brmkG9q49hgh4U32KACG9vPBx2nUZIZjANE/lozxNwu8v32+xwwcEySsfgBDHGdaSHKgaRIfrksPuC6Vbf4vJd6Bvbu4re9Zze1uBXfzzxUg6nbEY2Ue76cZoqEwKXCe9HWc/PxOljWEB15GLwp359cbbFLyQMBzwizyPQWn57bbsdTTnefl9FtPRVuv9tydlm2mHWrRDT18uZiogMMM+GJO51wfhj4KqihtzpA1xOjRKSpy657VKwtcguezcRdXO5W/8wi+O42UmjNiFgiYPHh702hwcY6Y683gxLPO0r7Tp7tmQjfiH1Q4G0F3RvO9bw uxRGXnU5 FuzwpB8AYAhtILLmmeToo2/g/tYWPnxKxQISkc96kiaIv6N7EMzj/AFQ8012/SsivyS1Tp9bLwmpKvrFTZ28FX+5Yq5hTBRwMf9CFX4agVyOyjmCc1XPA4kd+hYKc9IvED8IFeThGX8H4D/ZosQdihBSxWenlGUslQng6HcPRWW1zx4W9bCrMVrXgDWjkqhG+VkD5+B5Jy+CAvDdoZjb+RcP00vN+oaRjp5gX8ACTSrr114SpeLp1h2tT+nFIMvhD44TaH2wQwqH78FOqmDlUCBmi8K+hsp3GPlgRihivzmdJF0tQR3ojkXa7Xw== 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 Thu, 25 Jan 2024 17:59:40 -0800 Greg Kroah-Hartman wrote: > > I tried to use kernfs when doing a lot of this and I had issues. I > > don't remember what those were, but I can revisit it. > > You might, as kernfs makes it so that the filesystem structures are > created on demand, when accessed, and then removed when memory pressure > happens. That's what sysfs and configfs and cgroups use quite > successfully. kernfs doesn't look trivial and I can't find any documentation on how to use it. Should there be work to move debugfs over to kernfs? I could look at it too, but as tracefs, and more specifically eventfs, has 10s of thousands of files, I'm very concerned about meta data size. Currently eventfs keeps a data structure for every directory, but for the files, it only keeps an array of names and callbacks. When a directory is registered, it lists the files it needs. eventfs is specific that the number of files a directory has is always constant, and files will not be removed or added once a directory is created. This way, the information on how a file is created is done via a callback that was registered when the directory was created. For this use case, I don't think kernfs could be used. But I would still like to talk about what I'm trying to accomplish, and perhaps see if there's work that can be done to consolidate what is out there. -- Steve