From: "Keld Jørn Simonsen" <keld@dkuug.dk>
To: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: Performance question
Date: Wed, 21 Jan 2009 21:15:41 +0100 [thread overview]
Message-ID: <20090121201541.GA20499@rap.rap.dk> (raw)
In-Reply-To: <20090121191452.GA4752@lazy.lzy>
On Wed, Jan 21, 2009 at 08:14:52PM +0100, Piergiorgio Sartor wrote:
> Hi again,
>
> [--detail vs. --examine]
> > --detail looks at the running arrays, while --examine most
> > likely (depending on mdadm.conf) looks at all partitions
> > on the system.
> >
> > Given that the arrays are just created in the installation process, and
> > the active running arrays are most likely the ones you want your system
> > to know of, I think --detail is the better. --examine does on two of my
> > systems generate info that are in conflict and not suitable for a
> > mdadm.conf file, such as two /dev/md1 with different UUIDs.
>
> yes, but I noticed that with "--detail" and an
> array (RAID-1) resyincing, it reports "spares=1"
> too, while when the array is in sync, it prints
> the correct geometry.
> So, I was wondering, since I also noticed that
> "--examine" produces the arrays with /dev/md/"name",
> so if two arrays have same name, it ends up with
> the same device.
> Is this maybe a bug of mdadm?
I leave this to others to answer this one.
I think it is strange for --detail to report "spares=1"
if it is syncing.
> [metadata position]
> > To me it does not matter that much, except for the booting device.
> > Each partition in the booting device must look like a normal (ext3)
> > partition, as grub and lilo does not know of raids, and just treats
> > a booting partition as a standalone partition. So here you should use
> > 0.90 metadata, which is put at the end of the array.
>
> Well, I was a bit mixing up things with this question.
> In the back of my head the question was:
>
> What about performances, RAID-10 f2, bitmap (important)
> and metadata 1.0 vs. 1.1?
>
> This could be a further test for performances. It would
> be interesting to know if it is better to have the
> metadata at the beginning or at the end of a RAID-10 f2,
> with two HDs, having the bitmap enabled.
> Or if it does not matter at all.
>
> Reading around I found different "opinions" about bitmap
> and performances, but I did not find a "convincing" test.
I have not tested it. So yes, I think this is something to do a performance test
on. I think it should not matter much whether it is in the beginning or in
the end. However, if you make a test, then you most likely will do it on
a newly created raid, and then files would tend to be allocated in the
beginning of the file system, thus favouring a metadata block in the
beginning of the raid. In real operation this will tend to even out.
Another issue is that the sectors in the beginning of a disk are much
faster, a factor of two perhaps, than the sectors in the end of the
drive.
> Thanks again.
>
> Different item of the wiki, I run into it today.
> Maybe the "initrd" description could be updated, since
> it uses "mdassemble", while the "initrd" I have uses
> directly "mdadm -As --auto=yes ..." (I do not remember
> the full line).
mdasseble is specifically made for initrd, so why not use it here?
Best regards
keld
next prev parent reply other threads:[~2009-01-21 20:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-17 17:18 Performance question Piergiorgio Sartor
2009-01-17 18:37 ` Bill Davidsen
2009-01-17 22:08 ` Keld Jørn Simonsen
2009-01-19 18:12 ` Piergiorgio Sartor
2009-01-21 0:15 ` Keld Jørn Simonsen
2009-01-21 1:05 ` Richard Scobie
2009-01-21 19:14 ` Piergiorgio Sartor
2009-01-21 20:15 ` Keld Jørn Simonsen [this message]
2009-01-21 20:26 ` Piergiorgio Sartor
-- strict thread matches above, loose matches on Subject: below --
2009-01-17 18:11 David Lethe
2009-01-17 18:20 ` Piergiorgio Sartor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090121201541.GA20499@rap.rap.dk \
--to=keld@dkuug.dk \
--cc=linux-raid@vger.kernel.org \
--cc=piergiorgio.sartor@nexgo.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).