Do we need an opt-in for file systems use of hw atomic writes?

[John Garry]

On 14/07/2025 14:50, Christoph Hellwig wrote:
> On Mon, Jul 14, 2025 at 02:39:54PM +0100, John Garry wrote:
>> On 14/07/2025 14:17, Christoph Hellwig wrote:
>>> Hi all,
>>>
>>> I'm currently trying to sort out the nvme atomics limits mess, and
>>> between that, the lack of a atomic write command in nvme, and the
>>> overall degrading quality of cheap consumer nvme devices I'm starting
>>> to free really uneasy about XFS using hardware atomics by default without
>>> an explicit opt-in, as broken atomics implementations will lead to
>>> really subtle data corruption.
>>>
>>> Is is just me, or would it be a good idea to require an explicit
>>> opt-in to user hardware atomics?
>>
>> But isn't this just an NVMe issue? I would assume that we would look at such
>> an option in the NVMe driver (to opt in when we are concerned about the
>> implementation), and not the FS. SCSI is ok AFAIK.
> 
> SCSI is a better standard, and modulo USB devices doesn't have as much
> of an issue with cheap consumer devices.
> 
> But form the file system POV we've spent the last decade or so hardening
> file systems against hardware failures, so now suddenly using such a
> high risk feature automatically feels a bit odd.
> 

I see. I figure that something like a FS_XFLAG could be used for that. 
But we should still protect bdev fops users as well.

JFYI, I have done a good bit of HW and SW-based atomic powerfail testing 
with fio on a Linux dev board, so there is a decent method available for 
users to verify their HW atomics. But then testing power failures is not 
always practical. Crashing the kernel only tests AWUN, and AWUPF (for NVMe).