On Mon, Jun 06, 2011 at 10:38:07AM -0700, Brian Buhrow wrote: > Hello. I like this explanation. Can you help clarify by giving a > theoretical example? > -thanks > -Brian
If sectPerSU is the per-component stripe size, and let's say you have 4 disks (components), then I think the total size of a stripe will be 4*sectPerSU. If, for example, you create your filesystem with blocksize 32k, you'll want your sectPerSU to be 16 (i.e. 16 * 512 = 8k). eric -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? > On Jun 6, 9:50am, Thor Lancelot Simon wrote: > } Subject: Re: RAID stripe size (was: 5.1 RAID5 write performance) > } On Mon, Jun 06, 2011 at 03:24:15PM +0200, Edgar Fu? wrote: > } > > Ah, yes, the old > rmwrmwrmwrmwrmwrmwrmwrmwrmwrmwrmwrmwrmwrmwrmwrmwrmwrmwrmwrmwrmwrmwrmwrmwrmwrmwrmwrmwrmwrmwrmwrmw > cycle. Gets me every time. > } > OK, I've fixed that (before doing the tests I reported the last two days). > } > > } > So, what's the advantage of a larger sectPerSU? > } > It appears to me that the raidctl manpage should note that > } > -- the stripe size should match fsbsize > } > } Wait. I didn't notice this until just now. This is not right. > } > } The filesystem block size (or, where this is not possible, the maximum > } cluster size the filesystem will write) should be equal to sectPerSU > } times the number of data (not parity) disks. The sectPerSU value is > } the *per-component* stripe size, not the total amount of data written > } across all components in one stripe. > } > } Thor > >-- End of excerpt from Thor Lancelot Simon >