md man page

md man page

[Keld Jørn Simonsen]

Who is in charge of the linux man page for md(4)?
Neil?

I would like to have corrected som inaccuraties.

Best regards
keld

Re: md man page

[Randy.Dunlap]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 299 bytes --]

On Tue, 1 Jul 2008, Keld Jørn Simonsen wrote:

> Who is in charge of the linux man page for md(4)?
> Neil?
> 
> I would like to have corrected som inaccuraties.

In general, see http://kernel.org/doc/man-pages/
That web page has contact info and info on contributing.

Thanks.
-- 
~Randy

Re: md man page

[NeilBrown]

On Wed, July 2, 2008 6:22 am, Keld Jørn Simonsen wrote:
> Who is in charge of the linux man page for md(4)?
> Neil?

Yes, me.  It is part of the "mdadm" package.

>
> I would like to have corrected som inaccuraties.

I'm trying to decide if you are being ironic, or if your spelling
is simply as bad as mine. :-)
HOwever I'm always happy to receive updates and I'm sure we can
get the spelling/grammar right if we do it together.

NeilBrown


>
> Best regards
> keld
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: md man page

[Andre Noll]

[-- Attachment #1: Type: text/plain, Size: 471 bytes --]

On 07:21, NeilBrown wrote:

> HOwever I'm always happy to receive updates and I'm sure we can
> get the spelling/grammar right if we do it together.

As we are at it: I have a couple of simple patches against md.c. Mostly
trivial stuff that caught my eye while trying to understand the code in
that file. If you are interested, I can send the patches to the list.

Regards
Andre
-- 
The only person who always got his work done by Friday was Robinson Crusoe

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

raid10 layouts and performance Re: md man page

[Neil Brown]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 2923 bytes --]


(Adding linux-raid - I hope that's OK Keld?)

On Wednesday July 2, keld@dkuug.dk wrote:
> 
>        When 'offset' replicas are chosen, the multiple copies of a given chunk
>        are  laid out on consecutive drives and at consecutive offsets.  Effec-
>        tively each stripe is duplicated and  the  copies  are  offset  by  one
>        device.    This  should give similar read characteristics to 'far' if a
>        suitably large chunk size is used, but  without  as  much  seeking  for
>        writes.
> 
> A number of benchmarks have shown that 'offset' layout does not have 
> similar read characteristics as the 'far' layout. Also a number of benchmarks have
> shown that seeking is similar in 'far' and 'offset' layouts. So I suggest to
> remove the last sentence.

If I have done any such benchmarks, it was too long ago to remember,
so I decided to do some simple tests and graph them.  I like graphs
and I like this one so I've decided to share it.

The X axis is chunk size, ranging from 4k to 4096k - it is
logarithmic.
The Y axis is throughput in MB/s measured by 'dd' to the raw device -
average of 5 runs.
This was with a 2-drive raid with each of the possible layout: n2, f2,
o2.

f2-read is strikingly faster than anything else.  It is clearly
reading from both drives as once, as you would expect it to.
f2-write is slower then anything else (except at 4K chunk size, which is
an extreme case).

o2-read is fairly steady for most of the chunk sizes, but peaks up at
2M and only drops a little at 4M.  This seems to suggest that it is
around 2M that the time to seek over a chunk drops well below the time
to read one chunk.  Possibly at smaller chunk sizes, it just reads to
skip N sectors.  Maybe the cylinder size is about 2Meg - there no real
gain from the offset layout until you can seek over whole cylinders.
So the sentence:
      This  should give similar read characteristics to 'far' if a
      suitably large chunk size is used
seems somewhat justified if the chunksize used is 2M.
It might be interesting to implement non-power-of-2 chunksizes and try
a range of sizes between 1M and 4M to see what the graph looks like...
maybe we could find the actual cylinder size.

o2-write is very close to n2-write and is measurably (8%-14%) higher
than f2-write.  This seems to support the sentence
      but without as much seeking for writes.

It is not that there are fewer seeks, but that the seeks are shorter.

So while I don't want to just remove that last sentence, I agree that
it could be improved, possibly by giving a ball-park figure for what a
"suitably large chunk size" is.  Also the second half could be
"but without the long seeks being required for sequential writes".

It would probably be good to do some measurements with random IO as
well to see how they compare.

Anyone else have some measurements they would like to share?


Thanks for your suggestions.

NeilBrown



[-- Attachment #2: 10f2.png --]
[-- Type: image/png, Size: 4331 bytes --]

Re: raid10 layouts and performance Re: md man page

[Keld Jørn Simonsen]

On Tue, Jul 08, 2008 at 09:29:08AM +1000, Neil Brown wrote:
Content-Description: message body text
> 
> (Adding linux-raid - I hope that's OK Keld?)

Yeah, that is fine:-)

> On Wednesday July 2, keld@dkuug.dk wrote:
> > 
> >        When 'offset' replicas are chosen, the multiple copies of a given chunk
> >        are  laid out on consecutive drives and at consecutive offsets.  Effec-
> >        tively each stripe is duplicated and  the  copies  are  offset  by  one
> >        device.    This  should give similar read characteristics to 'far' if a
> >        suitably large chunk size is used, but  without  as  much  seeking  for
> >        writes.
> > 
> > A number of benchmarks have shown that 'offset' layout does not have 
> > similar read characteristics as the 'far' layout. Also a number of benchmarks have
> > shown that seeking is similar in 'far' and 'offset' layouts. So I suggest to
> > remove the last sentence.
> 
> If I have done any such benchmarks, it was too long ago to remember,
> so I decided to do some simple tests and graph them.  I like graphs
> and I like this one so I've decided to share it.

I like graphs too! May I use your graph on the wiki?

> The X axis is chunk size, ranging from 4k to 4096k - it is
> logarithmic.
> The Y axis is throughput in MB/s measured by 'dd' to the raw device -
> average of 5 runs.
> This was with a 2-drive raid with each of the possible layout: n2, f2,
> o2.
> 
> f2-read is strikingly faster than anything else.  It is clearly
> reading from both drives as once, as you would expect it to.
> f2-write is slower then anything else (except at 4K chunk size, which is
> an extreme case).

Yes, in your test. Is this done with dd on the raw array?

My tests indicate that writing is almost the same for raid10,n2 and
raid10,f2, when using the ext3 fs. I think the elevator comes into play
here. And I actually think this is important. You do not use an array
without a fs on top of it. And for the user, it is really the resulting
performance of the raid and the fs that is interesting. The raw array is
not that interesting.

> o2-read is fairly steady for most of the chunk sizes, but peaks up at
> 2M and only drops a little at 4M.  This seems to suggest that it is
> around 2M that the time to seek over a chunk drops well below the time
> to read one chunk.  Possibly at smaller chunk sizes, it just reads to
> skip N sectors.  Maybe the cylinder size is about 2Meg - there no real
> gain from the offset layout until you can seek over whole cylinders.
> So the sentence:
>       This  should give similar read characteristics to 'far' if a
>       suitably large chunk size is used
> seems somewhat justified if the chunksize used is 2M.

Your graph indicates that raid10,o2 is something like 20 % under the
performance of raid10,f2, in the best case. In the worst case it is
about 30 % under. To me this is not "similar". To me that is better
described as a performance of 20 - 30 % under that of raid10,f2.

> It might be interesting to implement non-power-of-2 chunksizes and try
> a range of sizes between 1M and 4M to see what the graph looks like...
> maybe we could find the actual cylinder size.
> 
> o2-write is very close to n2-write and is measurably (8%-14%) higher
> than f2-write.  This seems to support the sentence
>       but without as much seeking for writes.
> 
> It is not that there are fewer seeks, but that the seeks are shorter.

This is most likely compensated by the elevator, as described above.

> So while I don't want to just remove that last sentence, I agree that
> it could be improved, possibly by giving a ball-park figure for what a
> "suitably large chunk size" is.  Also the second half could be
> "but without the long seeks being required for sequential writes".
> 
> It would probably be good to do some measurements with random IO as
> well to see how they compare.
> 
> Anyone else have some measurements they would like to share?

There is something like more than a handful in the wiki at
http://linux-raid.osdl.org/index.php/Performance

This includes some tests for random IO.

> Thanks for your suggestions.

you are welcome!

In my quest for updated documentation for linux raid, I find that mdadm
documentation is also very outdated. The mdadm man page that is reported
by google, and on wikipedia for mdadm, do not include any info on
raid10! 

Is there a page that we could reference, which has the current mdadm man
page? And which is maintained?

I note that our raid wiki is now nbr 3 on google, That is a lot better
than number 121 which was the place about half a year ago:-)

Re: raid10 layouts and performance Re: md man page

[David Greaves]

Keld Jørn Simonsen wrote:
> In my quest for updated documentation for linux raid, I find that mdadm
> documentation is also very outdated. The mdadm man page that is reported
> by google, and on wikipedia for mdadm, do not include any info on
> raid10! 
> 
> Is there a page that we could reference, which has the current mdadm man
> page? And which is maintained?
Now the wiki is established I was hoping that we could somehow get the mdadm and
md documents integrated (though clearly they need to be manpages - maybe
asciidoc (as used by git) would be a good start.

I didn't want to do this by hand as it would need updating to be useful.

Hmm - having non-editable wiki pages automatically produced from something like
asciidoc and then allowing the discussion pages to annotate/xref them...

> 
> I note that our raid wiki is now nbr 3 on google, That is a lot better
> than number 121 which was the place about half a year ago:-)

I'm still having trouble with the LDP howto people - they said they'd deprecate
their page but there's a certain Rick Moen making life very difficult indeed!!
Perseverance...

David
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: raid10 layouts and performance Re: md man page

[Keld Jørn Simonsen]

On Wed, Jul 09, 2008 at 09:51:38AM +0100, David Greaves wrote:
> Keld Jørn Simonsen wrote:
> > In my quest for updated documentation for linux raid, I find that mdadm
> > documentation is also very outdated. The mdadm man page that is reported
> > by google, and on wikipedia for mdadm, do not include any info on
> > raid10! 
> > 
> > Is there a page that we could reference, which has the current mdadm man
> > page? And which is maintained?

> Now the wiki is established I was hoping that we could somehow get the mdadm and
> md documents integrated (though clearly they need to be manpages - maybe
> asciidoc (as used by git) would be a good start.
> 
> I didn't want to do this by hand as it would need updating to be useful.
> 
> Hmm - having non-editable wiki pages automatically produced from something like
> asciidoc and then allowing the discussion pages to annotate/xref them...

Neil is the one maintaining the man page. Maybe he has ideas on how to
have an updated reference page? Else I am happy with your suggestions.

best regards
keld
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html