From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-99.freemail.mail.aliyun.com (out30-99.freemail.mail.aliyun.com [115.124.30.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 893B327B337; Wed, 27 Aug 2025 09:58:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.99 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756288696; cv=none; b=AQ+ELplhFuaB9znyd5/AoOk7geKxXqH8sqIc3vkLomsPBOKtmeMF6bL3qV/ebr3fMGJgZZKHg3PbXe82ujl2SZOTVwex7iB26gGZ5YDl5sR0Hwn8lVFQiou7EMyejfYWywjyCc9xP3y8hHg8MvjrEcassDUp2r+Z8vJDcOPEkwE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756288696; c=relaxed/simple; bh=/Ir3rFh00106bX4RF58/hFmZNAZqe4EjsVSxf8bFFZ0=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=nY6DKBnVpx7Yemi40HTu1NohkLwuwf79pdt1zaaed2+FFNTJjNX+2EDUF7oFc3tBi/bfCsawWo8/i35unU+LZvoDMf1sNDHCbgq0f2YaDBxcxfY/1fbW8SjyYiWXTAWsOaTmdRqubLHms8+sA9kTTqBp761vKtCcqiJEfPA6PEU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=tKboMPw4; arc=none smtp.client-ip=115.124.30.99 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="tKboMPw4" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1756288684; h=Message-ID:Date:MIME-Version:Subject:From:To:Content-Type; bh=f5I6oWDR0PQgRWnuoQy+/ziRBVt2cA+qqfHQvEueHu0=; b=tKboMPw4FT9MkMaEBa1TVrd/w7qdc7VwSYx3mm1LHsAjytEpXAffwmmJuTqT2Op3zNgeco2FrStmudYjp44VXwmXMrB1l/3So1jf/Hxtk8V4sZe+tA5cIp6Ymg6d9uRwU+UmzfEbgBf6f/bYw1VG03xXGLr7V2phQDmwctBK1vw= Received: from 30.221.131.253(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0WmicTMP_1756288682 cluster:ay36) by smtp.aliyun-inc.com; Wed, 27 Aug 2025 17:58:03 +0800 Message-ID: <81788d65-968a-4225-ba1b-8ede4deb0f61@linux.alibaba.com> Date: Wed, 27 Aug 2025 17:58:02 +0800 Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] initrd: support erofs as initrd From: Gao Xiang To: Askar Safin Cc: Byron Stanoszek , Christoph Hellwig , gregkh , "julian.stecklina" , linux-fsdevel , linux-kernel , rafael , torvalds , viro , =?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= , Christian Brauner References: <20250321050114.GC1831@lst.de> <20250825182713.2469206-1-safinaskar@zohomail.com> <20250826075910.GA22903@lst.de> <6b77eda9-142e-44fa-9986-77ac0ed5382f@linux.alibaba.com> <198ead62fff.fc7d206346787.2754614060206901867@zohomail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2025/8/27 17:48, Gao Xiang wrote: > > > On 2025/8/27 17:22, Askar Safin wrote: >>   ---- On Tue, 26 Aug 2025 19:32:34 +0400  Gao Xiang wrote --- >>   > I completely agree with that point. However, since EROFS is a >>   > block-based filesystem (Thanks to strictly block alignment, meta(data) >>   > can work efficiently on both block-addressed storage >>   > devices and byte-addressed memory devices. Also if the fsblock size >> >> As I said previously, just put your erofs image to initramfs >> (or to disk) and then (in your initramfs init) create ramdisk out of it >> or loop mount it (both ramdisks and loop devices are block devices). >> >> This way you will have erofs on top of block device. >> >> And you will not depend on initrd. (Again: I plan to remove initial ramdisk >> support, not ramdisk support per se.) > > It doesn't work if end users put `init` into erofs image and sign > the whole erofs initram images with their certifications. > > And it doesn't have any relationship with cpio because users need > signed image and load from memory. Again, I don't think initramfs is the same concept as a golden signed initramdisk, and cpio doesn't support those advanced usage. The additional cpio extraction destroys bit-for-bit identical data protection, or some other new verification approach is needed for initramfs tmpfs. Thanks, Gao Xiang > > Thanks, > Gao Xiang