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).
