Date: Sun, 26 Jan 2025 20:56:47 +0100 From: Jonathan Krebs <jonny@lists.freebsd.org.olpp.net> To: freebsd-geom@freebsd.org Subject: Re: when does BIO_FLUSH happen on a disk? Message-ID: <2e177cef-f703-4572-abc0-665d8702b55f@lists.freebsd.org.olpp.net> In-Reply-To: <Z5RzjsoswJlTDwSI@kib.kiev.ua> References: <d8f6fee8-f52e-4787-8055-bdba16a820c4@lists.freebsd.org.olpp.net> <Z5RzjsoswJlTDwSI@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
@Konstantin Belousov: Thank You for the fast and helpful explanation! but does a finished write request from a disk / lower geli layer mean, that the data arrived on stable storage (in which case BIO_FLUSH seems unnecessary to exist) - or does fsync on UFS only guarantee ordering with respect to other operations on the same filesystem? On 1/25/25 06:15, Konstantin Belousov wrote: > The only case where UFS issues BIO_FLUSH, together with BIO_ORDERED flag, > to prevent reordering of the requests before/after the flush, is when > a journal segment is written. This is done to ensure that metadata blocks > are written after the conduit journal records are on the stable storage. > > Generally, UFS uses softupdates technique and relies on the callbacks from > the buffer write completions to update internal structures to indicate > metadata write progress. With such approach, there is no need to issue > flushes. For instance, when doing fsync(2) and scheduling writes required > to flush the metadata and data, we only return from syscall when disk > reported that all writes were done. > > The case above (for the journal segment write) could be considered as a > way to short-cut some additional code that would otherwise need to be > written.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2e177cef-f703-4572-abc0-665d8702b55f>