Re: [PATCH v6 4/7] xfs: Support FS_XFLAG_ATOMICWRITES

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

 



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




[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux