Date: Mon, 15 Jun 2020 12:33:53 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 247276] [fusefs] lockup when using mmap w/ direct_io Message-ID: <bug-247276-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D247276 Bug ID: 247276 Summary: [fusefs] lockup when using mmap w/ direct_io Product: Base System Version: 12.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: trapexit@spawn.link Attachment #215581 text/plain mime type: Created attachment 215581 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D215581&action= =3Dedit example mmap usage I'm the author of the FUSE based filesystem mergerfs. A user recently repor= ted that after updating to 12.1 some client software to mergerfs was locking up. rtorrent in particular.=20 rtorrent uses mmap. Linux's FUSE implementation is unable to handle mmap wh= en direct_io is enabled so I recommend to users not enable direct_io who need = any software leveraging mmap. The user hadn't read the docs and was using direc= t_io on FreeBSD. It appears that mmap does work on FreeBSD's FUSE implementation when direct_io is used so he had no issues. Once updated his setup started blocking and the apps became unkillable (wai= ting on IO). I wrote a simple mmap example to read and write to a shared mapped = file and could reproduce the issue. When direct_io is off everything works fine. If I enable direct_io I will s= ee read requests come into the mergerfs server and so long as I only read from= the mapped memory it works fine. When writing however as soon as it needs to fl= ush it seems to lock up. I don't see any write commands come in, the client app blocks and is unkillable, other calls into the filesystem seem to work brie= fly and then block. A stack trace of mergerfs seems to indicate that it is work= ing as normal and could take requests. If mergerfs is killed none of the clients receive an error from the syscalls they are blocked on. I've been able to reproduce this with sshfs by simply adding `direct_io` to= the mount options. Attached is an example that triggers it. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-247276-227>