On Mon, Sep 11, 2023 at 03:35:15PM +0200, David Disseldorp wrote: > On Mon, 11 Sep 2023 12:07:07 +1000, Dave Chinner wrote: > > On Sun, Sep 10, 2023 at 09:29:14PM -0400, Kent Overstreet wrote: > > > What I've got in bcachefs-tools is a much thinner mapping from e.g. > > > kthreads -> pthreads, block layer -> aio, etc. > > > > Right, and we've got that in userspace for XFS, too. If we really > > cared that much about XFS-FUSE, I'd be converting userspace to use > > ublk w/ io_uring on top of a port of the kernel XFS buffer cache as > > the basis for a performant fuse implementation. However, there's a > > massive amount of userspace work needed to get a native XFS FUSE > > implementation up and running (even ignoring performance), so it's > > just not a viable short-term - or even medium-term - solution to the > > current problems. > > > > Indeed, if you do a fuse->fs ops wrapper, I'd argue that lklfuse is > > the place to do it so that there is a single code base that supports > > all kernel filesystems without requiring anyone to support a > > separate userspace code base. Requiring every filesystem to do their > > own FUSE ports and then support them doesn't reduce the overall > > maintenance overhead burden on filesystem developers.... > > LKL is still implemented as a non-mmu architecture. The only fs specific > downstream change that lklfuse depends on is non-mmu xfs_buf support: > https://lore.kernel.org/linux-xfs/1447800381-20167-1-git-send-email-octavian.purdila@xxxxxxxxx/ That was proposed in 2015. > Does your lklfuse enthusiasm here imply that you'd be willing to > reconsider Octavian's earlier proposal for XFS non-mmu support? 8 years a long time, circumstances change and we should always be open to changing our minds when presented with new circumstances and/or evidence. Context: back in 2015 I was in the middle of a significant revamp of the kernel and userspace code - that was when the shared libxfs codebase was new and being actively developed, along with a significant rework of all the userspace shims. One of the things that I was looking at the time was pulling everything into userspace via libxfs that was needed for a native XFS-FUSE implementation. That project never got that far - maintainer burnout happened before that ever became a reality. In that context, lklfuse didn't really make a whole lot of sense for providing userspace XFS support via fuse because a native FUSE solution would be much better in most regards (especially performance). Things have changed a whole lot since then. We have less fs developers, we have a antagonistic, uncooperative testing "community", we have more code and releases to support, etc. If we go back to what I said earlier about the minimum requirements for a "community supported filesystem", it was about needing three things: - mkfs and fsck coverage - fstests support - syzbot doesn't get run on it Now reconsider lklfuse from this perspective. We have #1 for most filesystems, #2 is pretty trivial, and #3 is basically "syzbot + lklfuse > /dev/null"... IOWs, we can largely validate that lklfuse doesn't eat your data with relatively little extra effort. We can provide userspace with a viable, supported mechanism for unprivileged mounts of untrusted filesystem images that can't lead to kernel compromise. And, largely, we retain control of the quality of the lklfuse implementation because it's running the kernel code that we already maintain and support. Times change, circumstances change, and if we aren't willing to change our minds because we need to solve the new challenges presented to us then we should not be in decision making positions.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
