Date: Sat, 04 Feb 2023 23:15:19 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 269330] fusefs: data corruption with mmap and either o_direct or fspacectl Message-ID: <bug-269330-227-ZVIHqcnbcu@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-269330-227@https.bugs.freebsd.org/bugzilla/> References: <bug-269330-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D269330 Konstantin Belousov <kib@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kib@FreeBSD.org --- Comment #1 from Konstantin Belousov <kib@FreeBSD.org> --- I am confused by your question, quite possibly because you are confused by buffer cache vs. page cache difference. B_CACHE is the flag for buffers (as in struct buf). For vnodes which have non-NULL vp->v_object AKA VMIO buffers, the buffer is only a header referen= cing some number of pages belonging to v_object. It is not necessary for a buff= er to exist for each page on the object queue. In fact, since number of buffers is fixed, it is usual for buffers to be deconstructed shortly after all i/o requested through the buffer finished. Dirty pages (pages which have the dirty/PG_M bits set) are converted into dirty buffers by vm_object_page_clean() when page clean is requested in asy= nc mode. Then the dirty buffers are written out by buffer daemon. This is significant simplification, but it catches the intent. Hopefully this answers the question 1. For question 2, what do you mean by 'finding' the dirty pages? If there is a possibility that vnode has a dirty page on its queue, then vm_object_mightbedirty() returns true. To find actual dirty pages, you must iterate over the page queue for the object and see which page is dirty, either from PoV of MI VM layer (m->dirty) or pmap (PG_M etc). Note that si= nce writable mappings could exist accessed by other threads, some exercises are needed to have PG_M reading not racy, like pmap_remove_write() call which invalidates all managed writable mappings. See vm_object_page_clean() for = all the details. And note that the fact that the page is clean from VM PoV (either MI or pma= p) does not mean that the page data really hit the storage. As I wrote above, page daemon only converts dirty pages into dirty buffers, clearing the dirty bits in vm_page. The content is still dirty but now tracked by the buffer cache. --=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-269330-227-ZVIHqcnbcu>