Re: XFS on top RAID10 with odd drives count and 2 near copies

[Stan Hoeppner <stan@hardwarefreak.com>]

On 2/17/2012 1:03 PM, Peter Grandi wrote:

> As I have repeated many many many times to you in past XFS
> discussions, and please take note, stripe alignment matters ONLY
> AND SOLELY IF READ-MODIFY-WRITE is involved, and RADI10 never
> requires read-modify-write.

A wise Jedi once contradicted himself when he advised me to "never speak
in absolute terms".  A wiser Jedi would have said "don't speak in
absolute terms".

[...]
> Disclaimer: using stripe alignment even when it is not required
> may help a bit with scheduling, it being slightly akin to a
> larger block size, but not quite, but that is a secondary
> effect.

And the inevitable future contradiction is the reason.  The wisest of
Jedi once told me "do not leave performance on the table".  Whether you
consider this "scheduling" effect, or others, of write alignment on non
RMW devices to be secondary, it does have positive performance
implications, and should thus not be left on the table.

More importantly, and I could be mistaken, but IIRC, even absent an
underlying RMW block device, XFS journal writes benefit from alignment
due to a resulting lower ratio of write barriers issued to blocks
written, due to the larger stripe width write out.  And as we all know
(or should), write barriers can murder performance, especially for
metadata heavy workloads, as each barrier operation typically flushes
all the drives' caches.  Most mdraid users probably don't run BBWC RAID
cards in JBOD mode to avoid barriers, though I know of a few who do.  So
XFS write alignment on mdraid should be an issue for most everyone using
XFS, regardless of whether their array is parity RMW or not.

Both unaligned RMW and write barriers are performance killers.  Which
one has more blood on its hands I can't say.  I've never done such
testing nor come across a related paper.

-- 
Stan