On 01/07/2025 19:08, Darrick J. Wong wrote:
From: Darrick J. Wong <djwong@xxxxxxxxxx> Allow callers of mkfs.xfs to specify a desired maximum atomic write size. This value will cause the log size to be adjusted to support software atomic writes, and the AG size to be aligned to support hardware atomic writes. Signed-off-by: "Darrick J. Wong" <djwong@xxxxxxxxxx>
thanks, regardless of comments below, FWIW: Reviewed-by: John Garry <john.g.garry@xxxxxxxxxx>
goto validate;@@ -4971,6 +4998,140 @@ calc_concurrency_logblocks(return logblocks; }+#define MAX_RW_COUNT (INT_MAX & ~(getpagesize() - 1))+ +/* Maximum atomic write IO size that the kernel allows. */
FWIW, statx atomic write unit max is a 32b value, so we get a 2GB limit just from that factor
+static inline xfs_extlen_t calc_atomic_write_max(struct mkfs_params *cfg)
+{
+ return rounddown_pow_of_two(MAX_RW_COUNT >> cfg->blocklog);
+}
+
+static inline unsigned int max_pow_of_two_factor(const unsigned int nr)
+{
+ return 1 << (ffs(nr) - 1);
+}
+
+/*
+ * If the data device advertises atomic write support, limit the size of data
+ * device atomic writes to the greatest power-of-two factor of the AG size so
+ * that every atomic write unit aligns with the start of every AG. This is
+ * required so that the per-AG allocations for an atomic write will always be
+ * aligned compatibly with the alignment requirements of the storage.
+ *
+ * If the data device doesn't advertise atomic writes, then there are no
+ * alignment restrictions and the largest out-of-place write we can do
+ * ourselves is the number of blocks that user files can allocate from any AG.
+ */
+static inline xfs_extlen_t
+calc_perag_awu_max(
+ struct mkfs_params *cfg,
+ struct fs_topology *ft)
+{
+ if (ft->data.awu_min > 0)
+ return max_pow_of_two_factor(cfg->agsize);
+ return cfg->agsize;
out of curiosity, for out-of-place atomic writes, is there anything to stop the blocks being allocated across multiple AGs?
