On Thu, May 22, 2025 at 06:24:50PM +0200, Amir Goldstein wrote: > On Thu, May 22, 2025 at 1:58 AM Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > > > Hi everyone, > > > > DO NOT MERGE THIS. Three weeks later, I've mostly gotten the iomap caching working. This is probably most exciting for John, because we were talking earlier about uploading storage mappings to the fuse driver and this is what I've come up with. I'm running around trying to fix all the stuff that doesn't quite work right. Top of that list is timestamps and file attributes, because fuse no longer calls the fuse server for file writes. As a result, the kernel inode always has the most uptodate versions of the some file attributes (i_size, timestamps, mode) and just want to send FUSE_SETATTR whenever the dirty inode gets flushed. After I get that working I'm going to have to rewrite fuse2fs (or more likely just fork it) to be a lowlevel driver because as I've noted elsewhere in this thread, the upper level fuse library can assign multiple fuse nodeids for a single hardlinked inode. The only reason that worked for non-iomap fuse2fs is because we have a BKL and disable all caching. For fuse+iomap, this discrepancy between fuse nodeids and ext2 inumbers means that iomap just plain doesn't work with hardlinks because there are multiple struct fuse_inodes for each ondisk inode and the locking is just broken; and the iomap callouts are per-inode, not per-file which leads to multiple layering violations in the upper level fuse library. Also as Amir points out, path lookups on every operation is just *slow*. Interim branches can be found here: https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=fuse-iomap-cache_2025-06-13 https://git.kernel.org/pub/scm/linux/kernel/git/djwong/libfuse.git/log/?h=fuse-iomap-cache_2025-06-13 https://git.kernel.org/pub/scm/linux/kernel/git/djwong/e2fsprogs.git/log/?h=fuse2fs-iomap-cache_2025-06-13 https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfstests-dev.git/log/?h=fuse2fs_2025-06-13 (I'm not going to respam the list with patches right now because the quality as told by fstests isn't quite where I want it to be for such a thing. fuse2fs+iomap passes 87% of fstests (down from 89% without iomap) but that's still pretty bad.) --D
