From: Phillip Susi <psusi@cfl.rr.com>
To: Wiebe Cazemier <halfgaar@gmx.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Software RAID1 (with non-identical discs) performance
Date: Mon, 18 Dec 2006 13:34:05 -0500 [thread overview]
Message-ID: <4586DF1D.6040501@cfl.rr.com> (raw)
In-Reply-To: <em0pdq$r7o$2@sea.gmane.org>
Wiebe Cazemier wrote:
> When using non-identical discs (not just size, but also geometry) to contruct
> your array, you can never get the partitions of the underlying discs to be
> equal in size because the size of a partition can only be N*cylindersize,
> where cylindersize varies across discs; the array always assumes the size of
> the smallest partition. When one of the discs fails, you need to replace it
> and make a partition that is exactly equal in size to the array, but because
> that usually is impossible, it mostly will be bigger. To cover for this, I
> have always left a small bit of unpartioned space on my discs. This not only
> provides me with headroom in making the partitions on discs with different
> geometry, but it's also possible that brand B's 250 GB is a little smaller
> than brand A's, and staying (well) below the 250 GB, makes sure any 250 GB
> disc fits in the array.
The entire concept of geometry is a a carryover from days gone by.
These days it is just a farse maintained for backwards compatibility.
You can put fdisk into sector mode with the 'u' command and create
partitions of any number of sectors you desire, regardless of the
perceived geometry.
> My first question is, is this a necessary/convenient technique to ensure you
> can replace discs over time, especially when you can't get the exact same
> replacement disc?
I don't believe you need to do anything; md will simply not use the few
extra sectors at the end of the larger disk/partition and round down to
the appropriate size.
> My second question is about the performance impact of using non-identical discs
> and partitions. I can't really find any info about this, but I've read someone
> making the statement that it would slow things down.
Yes, it slows things down. You want to try to match disk speeds as
closely as possible for best performance.
> My third question: write performance of RAID1 is usually lower than non-RAID,
> because the data has to be sent over the bus twice. But, with for example an
> NForce4 based mainboard using SATA, does that matter? I don't know if the SATA
> ports are connected to the chipset by means of PCI express or hypertransport,
> but both should be able to handle the double data transfer with room to spare.
> So, as I understand it, as long as the kernel can perform both transfers
> simultaniously, there should be no slow down, because when writing, there will
> simply be two discs writing data simultaniously, at the same speed one drive
> would. Is this correct?
Theoretically yes, more time will be spent sending the data across the
bus twice, but most systems have enough spare capacity there that you
probably won't notice.
next prev parent reply other threads:[~2006-12-18 18:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-16 12:39 Software RAID1 (with non-identical discs) performance Wiebe Cazemier
2006-12-18 18:34 ` Phillip Susi [this message]
2006-12-19 14:16 ` Dick Streefland
2006-12-19 15:40 ` Wiebe Cazemier
2006-12-19 16:11 ` Dick Streefland
2006-12-19 12:22 ` Wiebe Cazemier
2006-12-19 14:02 ` Michael Tokarev
2006-12-19 15:43 ` Jan Engelhardt
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=4586DF1D.6040501@cfl.rr.com \
--to=psusi@cfl.rr.com \
--cc=halfgaar@gmx.net \
--cc=linux-kernel@vger.kernel.org \
/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