I'm glad we agree. 😄If the file range is a sparse hole, the directio setup will allocateThis is exactly what I explained when reviewing the code that
space and create an unwritten mapping before issuing the write bio. The
rest of the process works the same as preallocations and has the same
behaviors.
If the file range is allocated and was previously written, the write is
issued and that's all that's needed from the fs. After a crash, reads
of the storage device produce the old contents or the new contents.
rejected RWF_ATOMIC without O_DSYNC on metadata dirty inodes.
John, when you're back from vacation, can we get rid of this language
and all those checks under _is_dsync() in the iomap patch?
(That code is 100% the result of me handwaving and bellyaching 6 months
ago when the team was trying to get all the atomic writes bits working
prior to LSF and I was too burned out to think the xfs part through.
As a result, I decided that we'd only support strict overwrites for the
first iteration.)
Perhaps this ^^ is what we should be documenting here.Summarizing:Yup, that makes sense to me.
An (ATOMIC|SYNC) request provides the strongest guarantees (data
will not be torn, and all file metadata updates are persisted before
the write is returned to userspace. Programs see either the old data or
the new data, even if there's a crash.
(ATOMIC|DSYNC) is less strong -- data will not be torn, and any file
updates for just that region are persisted before the write is returned.
(ATOMIC) is the least strong -- data will not be torn. Neither the
filesystem nor the device make guarantees that anything ended up on
stable storage, but if it does, programs see either the old data or the
new data.
Fair 'enuf.Maybe we should rename the whole UAPI s/atomic/untorn/...Perhaps, though "torn writes" is nomenclature that nobody outside
storage and filesystem developers really knows about. All I ever
hear from userspace developers is "we want atomic/all-or-nothing
data writes"...