public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Wiebe Cazemier <halfgaar@gmx.net>
To: linux-kernel@vger.kernel.org
Subject: Re: Software RAID1 (with non-identical discs) performance
Date: Tue, 19 Dec 2006 13:22:46 +0100	[thread overview]
Message-ID: <em8lim$lqd$1@sea.gmane.org> (raw)
In-Reply-To: em0pdq$r7o$2@sea.gmane.org

For some reason, your message doesn't appear in the GMane mail-to-news gateway.
I've quoted your message here. Hopefully, the quoting isn't messed up.

> 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.

I remember when I did that, fdisk started complaining. But, I'm going to have
to experiment with this.

> > 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. 

If you can indeed make partitions equally big on different types of drives by
using sector mode, that would solve part of the problem. But what if a
replacement disk you got, is just a tad smaller than the original one, and
doesn't fit in the array? That's also a reason I always left some space
unpartitioned, since resizing the array to make it smaller, is a pain last
time I tried.

> Yes, it slows things down.  You want to try to match disk speeds as closely
as possible for best performance. 

My concern wasn't so much about the different speeds of the drives, but the
fact that they have a different geometry. But, because you said that is
simulated anyway, can I assume that as long as both drives are equal in speed,
using different types of drives doesn't matter?


  parent reply	other threads:[~2006-12-19 12:23 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
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 [this message]
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='em8lim$lqd$1@sea.gmane.org' \
    --to=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