On 03/10/2024 14:02, Christoph Hellwig wrote:
On Thu, Oct 03, 2024 at 01:48:41PM +0100, John Garry wrote:
On 30/09/2024 13:54, John Garry wrote:
@@ -352,11 +352,15 @@ xfs_sb_has_compat_feature(
#define XFS_SB_FEAT_RO_COMPAT_RMAPBT (1 << 1) /* reverse map btree */
#define XFS_SB_FEAT_RO_COMPAT_REFLINK (1 << 2) /* reflinked files */
#define XFS_SB_FEAT_RO_COMPAT_INOBTCNT (1 << 3) /* inobt block counts */
+#define XFS_SB_FEAT_RO_COMPAT_ATOMICWRITES (1 << 31) /* atomicwrites enabled */
+
BTW, Darrick, as you questioned previously, this does make xfs/270 fail...
until the change to a not use the top bit.
With the large block size based atomic writes we shoudn't even need
a feature flag, or am I missing something?
It really does not add much ATM.
It originated back with you mentioned that we need a generic common way
to enable atomic writes.
And then we had forcealign, which was tightly-coupled to enabling atomic
writes, e.g. enforce forcealign enabled and power-of-2 extsize.
But, apart from leveraging larger FS block size for atomic writes, I
still think that we will want forcealign or similar.
I don't have full tests results yet, but we already know that we see
performance degradation in some scenarios when going to a 4K -> 16K FS
block size. We're testing MySQL, and Redo Log performance/efficiency
significantly degrades with 16K FS block size.
Thanks,
John
