Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Where is fuse going? API cleanup, restructuring and more

[Gao Xiang <hsiangkao@linux.alibaba.com>]

Hi Jan,

On 2026/3/23 17:43, Jan Kara wrote:
> On Sun 22-03-26 13:14:55, Gao Xiang wrote:
>>
>>
>> On 2026/3/22 11:25, Demi Marie Obenour wrote:
>>
>>> The only exceptions are if the filesystem is incredibly simple
>>> or formal methods are used, and neither is the case for existing
>>> filesystems in the Linux kernel.
>>
>> Again, first, I don't think "simple" is a helpful and descriptive
>> word out of this kind of area:
>>
>> "simple" formats are all formats just archive the filesystem
>> data and metadata, but without any more use cases. No simpler
>> than that, because you need to tell vfs the file (meta)data
>> (even the file data is the garbage data), otherwise they won't
>> be called as filesystems.
>>
>> So why we always fall into comparing which archive filesystem
>> is simpler than others unless some bad buggy designs in those
>> "simple" filesystems.
>>
>> Here, I can definitely say _EROFS uncompressed format_ fits
>> this kind of area, and I will write down formally later if each
>> on-disk field has unexpected values like garbage numbers, what
>> the outcome.  And the final goal is to allow EROFS uncompressed
>> format can be mounted as the "root" into totally isolated
>> user/mount namespaces since it's really useful and no practical
>> risk.
>>
>> If any other kernel filesystem maintainers say that they can do
>> the same , why not also allow them do the same thing? I don't
>> think it's a reasonable policy that "due to EXT4, XFS, BtrFS
>> communities say that they cannot tolerate the inconsistent
>> consequence, any other kernel filesystem should follow the
>> same policy even they don't have such issue by design."
>>
>> In other words, does TCP/IP protocol simple? and is there no
>> simplier protocol for network data? I don't think so, but why
>> untrusted network data can be parsed in the kernel?  Does
>> TCP/IP kernel implementation already bugless?
> 
> So the amount of state TCP/IP needs to keep around is very small (I'd say
> kilobytes) compared to the amount of state a filesystem needs to maintain
> (gigabytes). This leads to very fundamental differences in the complexity
> of data structures, their verification, etc. So yes, it is much easier to
> harden TCP/IP against untrusted input than a filesystem implementation.

Thanks for the reply.

I just want to say I think the core EROFS format is not
complex too, but I don't want to make the deadly-simple
comparsion among potential simple filesystems, since
TCP/IP is not the deadly-simple one.

In brief, mounting as "root" in the isolated user/mount
namespace is absolutely our interest and useful to
container users, and as one of the author and maintainer
of EROFS, I can ensure EROFS can bear with untrusted
(meta)data.

> 
> And yes, when you have immutable filesystem, things are much simpler
> because the data structures and algorithms can be much simpler and as you
> wrote a lot of these inconsistencies don't matter (at least for the
> kernel). But once you add ability to modify the filesystem - here I don't
> think it matters whether through CoW or other means - things get
> complicated quickly and it gets much more complex to make your code
> resilient to all kinds of inconsistencies...

I only consider the COW approach using OverlayFS for example,
it just copies up (meta)data into another filesystem (the
semantics is just like copy the file in the userspace) and
the immutable filesystem image won't change in any case.

Overlayfs write goes through normal user write and the
writable filesystem is consistent, so I don't think it does
matter.  Or am I missing something? (e.g could you point
out some case which OverlayFS cannot handle properly?)

Thanks,
Gao Xiang

> 
> 								Honza