which is right at the edge of what I need. I want to read the doc on
stripe_cache_size before going huge, if that's K 10MB is a LOT of cache
when 256 works perfectly in RAID-0.
but they are basically unrelated. in r5/6, the stripe cache is absolutely
critical in caching parity chunks. in r0, never functions this way, though
it may help some workloads a bit (IOs which aren't naturally aligned to
the underlying disk layout.)
Any additional input appreciated, I would expect the speed to be (Ndisk
- 1)*SingleDiskSpeed without a huge buffer, so the fact that it isn't
as others have reported, you can actually approach that with "naturally"
aligned and sized writes.
I'm doing the tests writing 2GB of data to the raw array, in 1MB writes. The
array is RAID-5 with 256 chunk size. I wouldn't really expect any reads,
but how many disks? if your 1M writes are to 4 data disks, you
stand a chance of streaming (assuming your writes are naturally
aligned, or else you'll be somewhat dependent on the stripe cache.)
in other words, your whole-stripe size is ndisks*chunksize, and for
256K chunks and, say, 14 disks, that's pretty monstrous...
I think that's a factor often overlooked - large chunk sizes, especially
with r5/6 AND lots of disks, mean you probably won't ever do "blind"
updates, and thus need the r/m/w cycle. in that case, if the stripe cache
is not big/smart enough, you'll be limited by reads.
I'd like to experiment with this, to see how much benefit you
really get from using larger chunk sizes. I'm guessing that past 32K
or so, normal *ata systems don't speedup much. fabrics with higher
latency or command/arbitration overhead would want larger chunks.
tried was 2K blocks, so I can try other sizes. I have a hard time picturing
why smaller sizes would be better, but that's what testing is for.
larger writes (from user-space) generally help, probably up to MB's.
smaller chunks help by making it more likley to do blind parity updates;
a larger stripe cache can help that too.
I think I recall an earlier thread regarding how the stripe cache is used
somewhat naively - that all IO goes through it. the most important
blocks would be parity and "ends" of a write that partially update an
underlying chunk. (conversely, don't bother caching anything which
can be blindly written to disk.)
regards, mark hahn.
-
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
