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 D176CC7EE29 for ; Fri, 9 Jun 2023 17:29:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 51DAC8E0003; Fri, 9 Jun 2023 13:29:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4A6988E0002; Fri, 9 Jun 2023 13:29:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 346E58E0003; Fri, 9 Jun 2023 13:29:10 -0400 (EDT) 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 1DD8D8E0002 for ; Fri, 9 Jun 2023 13:29:10 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id B82744038A for ; Fri, 9 Jun 2023 17:29:09 +0000 (UTC) X-FDA: 80883895218.19.D35EEB9 Received: from mail.hallyn.com (mail.hallyn.com [178.63.66.53]) by imf26.hostedemail.com (Postfix) with ESMTP id E8381140004 for ; Fri, 9 Jun 2023 17:29:06 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=none; spf=pass (imf26.hostedemail.com: domain of serge@hallyn.com designates 178.63.66.53 as permitted sender) smtp.mailfrom=serge@hallyn.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686331747; a=rsa-sha256; cv=none; b=izg5GgSJjZrjDAXC0YoajOFutdUbpgskevfVo65TQag4EZd81rus6r3BEsI4UGuZFWSYTI S6m+gmDRQSITPeh7AZdmDk8lARS+Nzrzi6v21VG8din+MZ26X+hhnAJY77m0zGoBQKE1yM 1Glba+z6DX8HiOQkGnOjZp/F6ryA+oA= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=none; spf=pass (imf26.hostedemail.com: domain of serge@hallyn.com designates 178.63.66.53 as permitted sender) smtp.mailfrom=serge@hallyn.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686331747; 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; bh=afjj2LKe4dCq8WYkZ++V4UO6mMMxV+M4w8HkIWw/LPc=; b=V1GHhg2XC+VN8j4BVxVmHJM09JR3pAxLkVDlP/tc/rTETav/sLvsnhbeQG8Hmgq3BpfP3i 65gv4w5A+nTqExIKj+YYOh6RNNqo/nGgHIzUyfclxftdkZlLhFWfAb6FINBP4ore9/xfe1 KCv83o01UKw6GHGu0OCi1udx3SjBXIM= Received: from jerom (unknown [128.107.241.177]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: serge) by mail.hallyn.com (Postfix) with ESMTPSA id 70452993; Fri, 9 Jun 2023 12:29:01 -0500 (CDT) Date: Fri, 9 Jun 2023 12:28:52 -0500 From: Serge Hallyn To: Christian Brauner Cc: Colin Walters , "Ariel Miculas (amiculas)" , "linux-fsdevel@vger.kernel.org" , "rust-for-linux@vger.kernel.org" , "linux-mm@kvack.org" Subject: Re: [RFC PATCH 00/80] Rust PuzzleFS filesystem driver Message-ID: References: <20230609063118.24852-1-amiculas@cisco.com> <20230609-feldversuch-fixieren-fa141a2d9694@brauner> <20230609-nachrangig-handwagen-375405d3b9f1@brauner> <6b90520e-c46b-4e0d-a1c5-fcbda42f8f87@betaapp.fastmail.com> <20230609-breitengrad-hochdekoriert-06ff26b96c13@brauner> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230609-breitengrad-hochdekoriert-06ff26b96c13@brauner> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: E8381140004 X-Stat-Signature: zxxuocia853ajkk9eyaccxth7ijho381 X-HE-Tag: 1686331746-732213 X-HE-Meta: U2FsdGVkX19buWkD8flcwlyh4Fj7ngwtTp/ydR8L/LjApkHC4btG2Ha/YBX2gFBftJVmh2m5aqnLVRWjsu8PXOH2CebA81ptCElFBbhhGaxUMxnsmt2A8xECYTjxGU/H83G9j8EdDQOtB+0qtGygirgLl57om+RkXB4HYccGBQuFSFpipnPmNCTdCT5DkOdmFAYN7ULg5po3HsVsp4g7xsrwZIPzizpx7P8QOD/3rpeam1vgix7jpBjhEDn5IDDoZUFg6fMIF5w6yNRnOz+26J/nwQoCynsN+QcDuKGHCLaqr4Nt2+Q6E+oN7kLxNk9VXpbYMao62t//HiI1SRG/M2RRAuMR6ajytfpcfTWK1KzxehIVIpFTPdVb/JIrjMUmreCxFcRK8UCnTK0nSrrSPl8EKtQC9FRoWdm/CQtgWq7kom939bkfSKunEVX+5wNzlWcdBgzG1HZmLa10iuHetLehHRzeftATZoIju74ShXEiB8d+BXFGTvWnm9N+KqXK2T7h9XofS/DF941XES6vtWolcMSQl4LYdLv1imQ6KlEJlq0STzOMV3nWP3+jgg09jqClG8E2/jvOQmX1hJfZA5cUvVm4PQKf9aumwHyvNfI654rRKOu+oSxs0xanECREpTjmGylVZNcrw/3zdEeUX8MoEQK4TgjmBb/SxTMlpvj7DyF6JJxFxWkA/HrAXjZ6TLi9F8CTqeh1UodPsVtvGhbfHpPktVSdc1gZRWAOUcF+Z/IokkeMn4lzbNCm0zAROoB0Vq6r5Sk4ogBLWfxjwc0E4HwEniFayuNhcf06pLa5vtFV9ccabUY8yhKDA2gUv+9hnca6382MxuMAOulhpu2ivTYa/oi6uqr/jR+J3uaVoOn3pxXfINMlAclOkB4WpS74ydPywMdzxg9tJ+X+YiWyO0d6MuUut27cBmoOXLpH7bHrBSewrcVbq/y3s/mxoh5EgNA/RKJ8Ep2y1Ck 6obyqpbo b7wgzuGjLfa/5Hi4Y0g5IAYRjSv6gMfopSLwwcq0my8rLOArTm3DSK+PhlxDncNHccY+GDf0wgVg7EGDTsEGm0QiU98an5+QHrbM7+BlzBeQBryE= X-Bogosity: Ham, tests=bogofilter, spamicity=0.082549, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Jun 09, 2023 at 02:42:47PM +0200, Christian Brauner wrote: > On Fri, Jun 09, 2023 at 08:20:30AM -0400, Colin Walters wrote: > > > > > > On Fri, Jun 9, 2023, at 7:45 AM, Christian Brauner wrote: > > > > > > Because the series you sent here touches on a lot of things in terms of > > > infrastructure alone. That work could very well be rather interesting > > > independent of PuzzleFS. We might just want to get enough infrastructure > > > to start porting a tiny existing fs (binderfs or something similar > > > small) to Rust to see how feasible this is and to wet our appetite for > > > bigger changes such as accepting a new filesystem driver completely > > > written in Rust. > > > > (Not a kernel developer, but this argument makes sense to me) > > > > > But aside from the infrastructure discussion: > > > > > > This is yet another filesystem for solving the container image problem > > > in the kernel with the addition of yet another filesystem. We just went > > > through this excercise with another filesystem. So I'd expect some > > > reluctance here. Tbh, the container world keeps sending us filesystems > > > at an alarming rate. That's two within a few months and that leaves a > > > rather disorganized impression. > > > > I am sure you are aware there's not some "container world" > > monoculture, there are many organizations, people and companies here > > That submission here explicitly references OCI v2. Composefs explicitly > advertises 100% compatibility with OCI. So, there's a set of OCI specs OCI v2 doesn't currently exist :) There were many design goals for it, and near as I can tell, after everyone discussed those together, everyone went off to work on implementing the bits the needed - which is a right and proper step before coming back and comparing notes about what went well, etc. The two main things where puzzlefs is experimenting are the use of content defined chunking (CDC), and being written in rust (and, especially, to have the same rust code base be used for the in kernel driver, the fuse mounter, the builder, and the userspace extractor). (Well, and reproducible images through a canonical representation, but...) It requires a POC in order to really determine whether the CDC will be worth it, or will have pitfalls. So far, it looks very promising. Adding that functionality to composefs one day could be cool. Likewise, it requires a user in order to push on the infrastructure required to support a full filesystem in rust in the kernel. But that really isn't something we can "add to composefs". :) The main goal of this posting, then, was to show the infrastructure pieces and work on that with the community. We're definitely not (currently :) asking for puzzlefs to be included. However, it is our (business and personal) justification for the rest of the work. > including runtime and image. As far as I'm concerned you're all one > container world under the OCI umbrella. One big happy family! > We're not going to push multiple filesystems into the kernel that all do > slightly different things but all serve the OCI container world and use > some spec as an argument to move stuff into the kernel. > > The OCI initiative is hailed as unifying the container ecosystem. Hence, > we can expect coordination.