Re: [RFC PATCH V2 01/12] fs/stat: Define DAX statx attribute
From: Dave Chinner
Date: Sat Jan 18 2020 - 04:11:29 EST
On Wed, Jan 15, 2020 at 10:05:00PM -0800, Dan Williams wrote:
> On Wed, Jan 15, 2020 at 9:39 PM Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote:
> [..]
> > > attempts to minimize software cache effects for both I/O and
> > > memory mappings of this file. It requires a file system which
> > > has been configured to support DAX.
> > >
> > > DAX generally assumes all accesses are via cpu load / store
> > > instructions which can minimize overhead for small accesses, but
> > > may adversely affect cpu utilization for large transfers.
> > >
> > > File I/O is done directly to/from user-space buffers and memory
> > > mapped I/O may be performed with direct memory mappings that
> > > bypass kernel page cache.
> > >
> > > While the DAX property tends to result in data being transferred
> > > synchronously, it does not give the same guarantees of
> > > synchronous I/O where data and the necessary metadata are
> > > transferred together.
> >
> > (I'm frankly not sure that synchronous I/O actually guarantees that the
> > metadata has hit stable storage...)
>
> Oh? That text was motivated by the open(2) man page description of O_SYNC.
Ugh. "synchronous I/O" means two different things, depending on
context. In the AIO context, it means "process context waits for operation
completion direct", but in the O_SYNC context, it means "we guarantee
data integrity for each I/O submitted".
Indeed, O_SYNC AIO is a thing. i.e. we can do an "async sync
write" to guarantee data integrity without directly waiting for
it. Now try describing that only using the words "synchronous
write" to describe both behaviours. :)
IOWs, if you are talking about data integrity, you need to
explicitly say "O_SYNC semantics", not "synchronous write", because
"synchronous write" is totally ambiguous without the O_SYNC context
of the open(2) man page...
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx