Re: [PATCH 6/6] generic: various atomic write tests with scsi_debug

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 14/05/2025 17:01, Darrick J. Wong wrote:
It seems many sub-tests are same as 1222

It is difficult to factor them out?
Yes.  g/1222 will _notrun itself if the scsi_debug module isn't present
or the fake device cannot be created.  Apparently many of the people who
run fstests also have test infrastructure that cannot handle modules, so
they don't run anything involving scsi_debug.

ok...


That's why g/1223 only requires that the scratch fs advertises some sort
of atomic write capability, it doesn't care how it provides that.

<snip>

diff --git a/tests/generic/1224 b/tests/generic/1224
new file mode 100644
index 00000000..fb178be4
--- /dev/null
+++ b/tests/generic/1224

<snip>


But we also test RWF_NOWAIT at some stage?

RWF_NOWAIT should fail always for filesystem-based atomic write
It's hard to test NOWAIT because the selected io path might not actually
encounter contention, and there are various things that NOWAIT will wait
on anyway (like memory allocation and metadata reads).

The filesystem-based atomic write will always try to allocate blocks, and this will fail for NOWAIT.

But, come to think of it, this is not even a useful test - so forget the suggestion. I was just testing this as a sanity check to prove that we are getting expected behavior.


<snip>


diff --git a/tests/xfs/1217 b/tests/xfs/1217
new file mode 100755
index 00000000..012a1f46
--- /dev/null
+++ b/tests/xfs/1217
@@ -0,0 +1,70 @@
+#! /bin/bash
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (c) 2025 Oracle.  All Rights Reserved.
+#
+# FS QA Test 1217
+#
+# Check that software atomic writes can complete an operation after a crash.
+#
Could we prove that we get a torn write for a regular non-atomic write also?
Perhaps?  But I don't see the point -- non-atomic write completions
could be done atomically.

oh, from my reading of the test, I thought that we were ensuring that we are writing over many extents, and so could not be completed atomically for a non-atomic write.

BTW, there is a typo in a comment for that test, please see "ssecond block"

Thanks,
John





[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux