[ ... ] > To my mind, stripe width applies to reads and writes. For > reads, it is the number of spindles that are used in parallel > while reading larger blocks of data. For writes, it is in > addition the width of a parity stripe for raid5 or raid6. In the XFS case that's completely wrong, and irrelevant: in the XFS case it is the number of sectors/blocks that IO has to be _aligned_ to avoid read-modify-write, if there is the risk for that. The stripe width per se matters less than aligned writes as to avoiding read-modify-write impact: if one does IO in stripe width units but they are not aligned, performance will be terrible as double read-modify-write will not be prevented. What is the stripe width does not matter to applications like a filesystem other than for read-modify-write avoidance because how many sectors/blocks are/can be read in parallel depends primarily on application access patterns, and secondarily on how good is the IO subsystem scheduling. > [ ... ] Some filesystems care a /little/ about stripe width in > that they align certain structures to stripe boundaries to > make accesses more efficient. That in the case where read-modify-write cannot happen, if read-modify write can happen, unaligned or non-full-width writes are very costly, and not just for arrays; it happens in RAM too, and for 4KiB physical sector drives simulating 512B logical sectors. -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
