Hi,
On 2022-01-28 08:01:01 +1300, Thomas Munro wrote:
> On Fri, Jan 28, 2022 at 7:28 AM Andres Freund <andres@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