Mainlining the kernel module for TernFS, a distributed filesystem

["Francesco Mazzoli" <f@mazzo.li>]

My workplace (XTX Markets) has open sourced a distributed
filesystem which has been used internally for a few years, TernFS:
<https://github.com/XTXMarkets/ternfs>. The repository includes both the server
code for the filesystem but also several clients. The main client we use
is a kernel module which allows you to mount TernFS from Linux systems. The
current codebase would not be ready for upstreaming, but I wanted to gauge
if eventual upstreaming would be even possible in this case, and if yes,
what the process would be.

Obviously TernFS currently has only one user, although we run on more than
100 thousand machines, spanning relatively diverse hardware and running
fairly diverse software. And this might change if other organizations adopt
TernFS now that it is open source, naturally.

The kernel module has been fairly stable, although we need to properly adapt
it to the folio world. However it would be much easier to maintain it if
it was mainlined, and I wanted to describe the peculiarities of TernFS to
see if it would be even possible to do so. For those interested we also
have a blog post going in a lot more detail about the design of TernFS
(<https://www.xtxmarkets.com/tech/2025-ternfs/>), but hopefully this email
would be enough for the purposes of this discusion.

TernFS files are immutable, they're written once and then can't be modified.
Moreover, when files are created they're not actually linked into the
directory structure until they're closed. One way to think about it is that
in TernFS every file follows the semantics you'd have if you opened the file
with `O_TMPFILE` and then linked them with `linkat`. This is the most "odd"
part of the kernel module since it goes counter pretty baked in assumptions
of how the file lifecycle works.

TernFS also does not support many things, for example hardlinks, permissions,
any sort of extended attribute, and so on. This is I would imagine less
unpleasant though since it's just a matter of getting ENOTSUP out of a bunch
of syscalls.

Apart from that I wouldn't expect TernFS to be that different from Ceph or
other networked storage codebases inside the kernel.

Let me know what you think,
Francesco