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

[Jan Kara <jack@suse.cz>]

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.

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...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR