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