[PATCH v7 2/9] fs: Initial atomic write support

[Dave Chinner]

On Thu, Jun 06, 2024 at 07:38:41AM +0100, John Garry wrote:
> On 06/06/2024 06:41, Christoph Hellwig wrote:
> > On Wed, Jun 05, 2024 at 11:48:12AM +0100, John Garry wrote:
> > > I have no strong attachment to that name (atomic).
> > > 
> > > For both SCSI and NVMe, it's an "atomic" feature and I was basing the
> > > naming on that.
> > > 
> > > We could have RWF_NOTEARS or RWF_UNTEARABLE_WRITE or RWF_UNTEARABLE or
> > > RWF_UNTORN or similar. Any preference?
> > 
> > No particular preference between any of the option including atomic.
> > Just mumbling out aloud my thoughts :)
> 
> Regardless of the userspace API, I think that the block layer terminology
> should match that of the underlying HW technology - so I would plan to keep
> "atomic" in the block layer, including request_queue sysfs limits.
> 
> If we used RWF_UNTORN, at some level the "atomic" and "untorn" terminology
> would need to interface with one another. If it's going to be insane to have
> RWF_UNTORN from userspace being translated into REQ_ATOMIC, then I could
> keep RWF_ATOMIC.
> 
> Someone please decide ....

RWF_ATOMIC for the user interface, please. An "atomic" IO operation is
easy for application developers to understand and reason about,
whilst "untorn" or some variant of "torn" will require us having to
repeated explain that it is a technical storage term that simply
means "the IO will be completed atomically".

-Dave.
-- 
Dave Chinner
dchinner at redhat.com