On Thu, May 22, 2025 at 09:49:15AM -0400, Theodore Ts'o wrote: > On Wed, May 21, 2025 at 10:11:33PM +0100, Tim Woodall wrote: > > > > when doing rm of a very large file (or possibly just a file whose block > > extends past 2^32-1) it fails with > > > > FUSE2FS-remove_inode: put ino=12 links=1 > > fuse: bad error value: 75 > > unique: 16, error: -34 (Numerical result out of range), outsize: 16 > > rm: cannot remove 'mount/filler': Numerical result out of range > > > > rm in debugfs does work. Attached patch replaces the deallocate block > > logic with that from debugfs. > > > > This possibly points to a bug in the underlying ext2_punch routine that > > fuse2fs is using but I haven't tried to investigate further. This > > function is also called from punch_helper so I suspect that using > > fallocate to punch holes might also have problems. > > Tim, > > Thanks for sending this bug report. As it turns out, Darrick has been > doing a huge amount of work fixing a large number of bugs in fuse2fs > by running it through fstests. He's also done some great work > improving the perforance of fuse2fs. > > I don't *think* your bug report has been addressed by the patches > Darrck has sent me, either the ones which I've already accepted into > the e2fsprgs git repo, or the 90 patches that just showed up in my inbox > this morning. :-) > > But perhaps I missed something, or it might be one of the patches that > Darrck has queed up but which he hasn't sent upstream yet. Darrick, > does this report ring a bell? Tim's proposed patches and reprducer > can be found at: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1106241
/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. 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. https://lore.kernel.org/linux-ext4/174786678650.1385354.14994099236248944550.stgit@frogsfrogsfrogs/T/#t 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 Anyway thank you very much for sending patches and stuff!!! We could use more people like you. :) --Darrick
