On Fri, Jun 06, 2025 at 03:54:50PM +0200, Miklos Szeredi wrote: > On Sat, 31 May 2025 at 03:08, Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > > The best reason that I can think of is that normally the process that > > owns the fd (and hence is releasing it) should be made to wait for > > the release, because normally we want processes that generate file > > activity to pay those costs. > > That argument seems to apply to all fuse variants. But fuse does get > away with async release and I don't see why fuseblk would be different > in this respect. > > Trying to hack around the problems of sync release with a task flag > that servers might or might not have set does not feel a very robust > solution. > > > Also: is it a bug that the kernel only sends FUSE_DESTROY on umount for > > fuseblk filesystems? I'd have thought that you'd want to make umount > > block until the fuse server is totally done. OTOH I guess I could see > > an argument for not waiting for potentially hung servers, etc. > > It's a potential DoS. With allow_root we could arguably enable > FUSE_DESTROY, since the mounter is explicitly acknowledging this DoS > possibilty. <nod> Looking deeper at fuse2fs's op_destroy function, I think most of the slow functionality (writing group descriptors and the primary super and fsyncing the device) ought to be done via FUSE_SYNCFS, not FUSE_DESTROY. If I made that change, I think op_destroy becomes very fast -- all it does is close the fs and log a message. The VFS unmount code calls sync_filesystem (which initiates a FUSE_SYNCFS) which sounds like it would work for fuse2fs. Unhappily, libfuse3 doesn't seem to implement it: $ git grep FUSE_SYNCFS doc/libfuse-operations.txt:394:50. FUSE_SYNCFS (50) include/fuse_kernel.h:186: * - add FUSE_SYNCFS include/fuse_kernel.h:670: FUSE_SYNCFS = 50, --D > Thanks, > Miklos
