@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.
