Hi, On 2022-01-28 08:01:01 +1300, Thomas Munro wrote: > On Fri, Jan 28, 2022 at 7:28 AM Andres Freund <and...@anarazel.de> wrote: > > On 2022-01-27 19:55:45 +0200, Heikki Linnakangas wrote: > > > I was not able to reproduce this without the tablespace on a different > > > virtual disk, I presume because ext4 orders the writes so that the > > > checkpoint implicitly always flushes the creation of the file to disk. > > > > It's likely that the control file sync at the end of a checkpoint has the > > side > > effect of also forcing the file creation to be durable if on the same > > > tablespace (it'd not make the file contents durable, but they don't exist > > here, so ...). > > It might be possible to avoid that on xfs or pretty much any other > file system. I wasn't following this closely, but even with ext4's > recent fast commit changes, its fsync implementation still > deliberately synchronises data for other file descriptors as a side > effect as summarised in [1], unlike xfs and other systems.
Not data, just metadata, right? Well, and volatile write caches (by virtue of doing an otherwise unnecessary REQ_PREFLUSH). With data=writeback file contents for file a are not flushed to disk (rather than from disk write cache) when file b is fsynced. Before/After the fast commit feature. > So they've caught up with xfs's concurrent writes (and gone further than xfs > by doing it also for buffered I/O giving up even page-level atomicity, as > discussed in a couple of other threads), but not yet decided to pull the > trigger on just-fsync-what-I-asked-for. I don't think the page level locking and the changes above / fsyncing are pretty much independent? Greetings, Andres Freund
