If the stripe width of a device is only 2x or 1x the stripe unit, there
is no parity disk on this device, and setting a larger log stripe unit
will not avoid any RMW cycles. However, a large log stripe unit does
have significant penalties for IO amplification because every log write
will be rounded up to the log stripe unit.
This was recently highlighted by a user running bonnie++ in sync mode,
where the default RAID10 geometry of 256k/512k yielded results which
were 4x slower than a smaller log stripe unit. While bonnie++ may not
be the benchmark of choice, it does highlight this issue.
Because a larger log stripe unit yields no RMW benefit on a device with
no parity disks, avoid setting in these cases.
Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx>
---
... thoughts?
Am I missing a reason why we /would/ still want lsunit in this case?
diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c
index 2e6cd280..4da69b29 100644
--- a/mkfs/xfs_mkfs.c
+++ b/mkfs/xfs_mkfs.c
@@ -2407,13 +2407,15 @@ _("log stripe unit (%d) must be a multiple of the block size (%d)\n"),
}
/*
- * check that log sunit is modulo fsblksize or default it to dsunit.
+ * check that log sunit is modulo fsblksize or default it to dsunit
+ * if this looks like a parity device (swidth > 2x sunit).
*/
if (lsunit) {
/* convert from 512 byte blocks to fs blocks */
cfg->lsunit = DTOBT(lsunit, cfg->blocklog);
} else if (cfg->sb_feat.log_version == 2 &&
- cfg->loginternal && cfg->dsunit) {
+ cfg->loginternal && cfg->dsunit &&
+ (cfg->dswidth / cfg->dsunit > 2)) {
/* lsunit and dsunit now in fs blocks */
cfg->lsunit = cfg->dsunit;
}
