For reasons I don't understand I don't get notified about updates to
bugs so this isn't a proper reply but I've cut and pasted your comments
from the bug report.
/me is on vacation today, but here's my hot take on the patches attached
to 1106241:
rm-fix.patch: we really need to figure out why that's borking up the
extent tree -- is it the punch itself that leaves things in a ruined
state, or something else that set up the tree that way? I noticed in my
stupid testing of non-iomap fuse2fs that if I fallocated 600M, wrote all
600M, and then did random reads/writes that I'd end up with a similarly
broken extent tree.
At least for my test, doing the rm via
debugfs -w -R "rm filler" "${DEV}"
works without issue (my fix is just a cut and paste of what debugfs does
in place of the call to ext2fs_punch) so I don't think the extent tree
is corrupted at this point.
test.sh: oooh reproducer, thank you!
inusefile.patch: Have you observed that umounting a fuse2fs mount
returns immediately but the fuse2fs server itself keeps running (and
flushing dirty data to disk) for several seconds more? That I think is
a bug/antifeature in the kernel and the solution to that is to move to a
fuseblk mount. OTOH if you're actually seeing this with regular files
then yeah, some other kind of locking is needed.
Yes, I'm seeing this with regular files being mounted and for test.sh on
my system it's around 50s
(Note that this is inside another fuse mount as the system I'm running
the tests on has 1K blocks so I cannot create a 5T sparse file to
contain the filesystem)
tim@dirac:/mnt/nobackup/test-fuse (none)$ truncate -s 5T fs
truncate: failed to truncate 'fs' at 5497558138880 bytes: File too large
For the most recent run of test.sh:
mke2fs of a 5T filesystem:
real 0m48.137s
Creating the 4T file:
make filler Thu 22 May 19:21:21 BST 2025 - this is slow
real 1m45.895s
Umounting after that:
fusermount -u mount Thu 22 May 19:23:07 BST 2025
real 0m0.004s
but...
Waiting for fuse to complete
Waiting for fuse to complete
Waiting for fuse to complete
Waiting for fuse to complete
It takes 30-40s to finishe and actually remove that lock file after it
returns.
rm filler (with the latest patches)
rm filler Thu 22 May 19:24:10 BST 2025 - this is slow
real 8m18.754s
unmounting again:
fusermount -u mount Thu 22 May 19:32:29 BST 2025
real 0m0.004s
but...
Waiting for fuse to complete
Waiting for fuse to complete
Waiting for fuse to complete
https://lore.kernel.org/linux-ext4/174786678650.1385354.14994099236248944550.stgit@frogsfrogsfrogs/T/#t
I will give that a try but won't be until the weekend.
lseek.patch: Yeah, that seems to work, though one fringe benefit of
hooking fuse2fs up to iomap is that you get FIEMAP and SEEK_{DATA,HOLE}
for free, in addition to much better performance:
https://lore.kernel.org/linux-ext4/174787198370.1484996.3340565971108603226.stgit@frogsfrogsfrogs/T/#u
I will give this a try too.
FWIW, they're not pushed yet, but I've ported all of the tests here:
https://sourceforge.net/p/dump/code/ci/main/tree/testing/scripts/
to work with libfuse so I can work on this without being root and all
pass (with the exception of a couple that I expect to take an
inordinately long length of time that I haven't tried yet)
The lseek patch is a modified version of code from here :-)
Tim.
