On Thu, Feb 29, 2024 at 09:23:35AM -0500, Phillip Susi wrote: > > So because no metadata changed, jbd2 will not issue a barrier to end the > transaction? How can we fix this then? Is there some way that jbd2 can > know whether file data has been written, and thus, issue the barrier to > close the transaction? Because no metadata changed, jbd2 will not even *start* a (jbd2) transaction as a result of that write (overwrite) to an already allocated data block.. Since it didn't start a jbd2 transaction for this file system operation, there's no reason to force a jbd2 transaction to close. (Note: this could because there *is* no currently existing open transaction, or there might be a currently open transaction, but it's not relevent to the activity associated with the file descriptor being fsync'ed.) This is a critical performance optimization, because for many database workloads, which are overwriting existing blocks and using fdatasync(2), there is no reason to force a jbd2 transaction commit for every single fdatasync(2) issued by the database. However, we still need to send a cache flush operation so that the data block is safely persistend onto stable storage. Cheers, - Ted
