linux-kernel - Re: [PATCH v2 1/4] erofs: add file-backed mount support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e0a6cccc-c982-4d8c-95a4-afa63da6aa7b@kernel.org>
Date: Thu, 5 Sep 2024 16:22:03 +0800
From: Chao Yu <chao@...nel.org>
To: Gao Xiang <hsiangkao@...ux.alibaba.com>, linux-erofs@...ts.ozlabs.org
Cc: LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/4] erofs: add file-backed mount support

On 2024/8/30 11:28, Gao Xiang wrote:
> It actually has been around for years: For containers and other sandbox
> use cases, there will be thousands (and even more) of authenticated
> (sub)images running on the same host, unlike OS images.
> 
> Of course, all scenarios can use the same EROFS on-disk format, but
> bdev-backed mounts just work well for OS images since golden data is
> dumped into real block devices.  However, it's somewhat hard for
> container runtimes to manage and isolate so many unnecessary virtual
> block devices safely and efficiently [1]: they just look like a burden
> to orchestrators and file-backed mounts are preferred indeed.  There
> were already enough attempts such as Incremental FS, the original
> ComposeFS and PuzzleFS acting in the same way for immutable fses.  As
> for current EROFS users, ComposeFS, containerd and Android APEXs will
> be directly benefited from it.
> 
> On the other hand, previous experimental feature "erofs over fscache"
> was once also intended to provide a similar solution (inspired by
> Incremental FS discussion [2]), but the following facts show file-backed
> mounts will be a better approach:
>   - Fscache infrastructure has recently been moved into new Netfslib
>     which is an unexpected dependency to EROFS really, although it
>     originally claims "it could be used for caching other things such as
>     ISO9660 filesystems too." [3]
> 
>   - It takes an unexpectedly long time to upstream Fscache/Cachefiles
>     enhancements.  For example, the failover feature took more than
>     one year, and the deamonless feature is still far behind now;
> 
>   - Ongoing HSM "fanotify pre-content hooks" [4] together with this will
>     perfectly supersede "erofs over fscache" in a simpler way since
>     developers (mainly containerd folks) could leverage their existing
>     caching mechanism entirely in userspace instead of strictly following
>     the predefined in-kernel caching tree hierarchy.
> 
> After "fanotify pre-content hooks" lands upstream to provide the same
> functionality, "erofs over fscache" will be removed then (as an EROFS
> internal improvement and EROFS will not have to bother with on-demand
> fetching and/or caching improvements anymore.)
> 
> [1] https://github.com/containers/storage/pull/2039
> [2] https://lore.kernel.org/r/CAOQ4uxjbVxnubaPjVaGYiSwoGDTdpWbB=w_AeM6YM=zVixsUfQ@mail.gmail.com
> [3] https://docs.kernel.org/filesystems/caching/fscache.html
> [4] https://lore.kernel.org/r/cover.1723670362.git.josef@toxicpanda.com
> 
> Closes: https://github.com/containers/composefs/issues/144
> Signed-off-by: Gao Xiang <hsiangkao@...ux.alibaba.com>

Reviewed-by: Chao Yu <chao@...nel.org>

Thanks,