Hi,
I'm planning to put a software RAID1 array in my computer, but I have a few
technical questions.
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.
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?
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.
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?
Thanks in advance,
Wiebe Cazemier
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.
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?
Wiebe Cazemier wrote:
> 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.
[]
> 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?
Think of "PnP geometry" supported by all nowadays drives.
It's 255 heads, 63 sectors per track, and whatever number of cylinders.
You start cfdisk (sorry don't remember options for other *fdisk) like this,
on an empty disk:
cfdisk -H 255 -S 63 /dev/sda
And after creating the partition table, kernel switches to this "PnP geometry"
mode automatically.
So regardless of how many actual heads or sectors your HDD has, it will always
work the same way.
/mjt
Phillip Susi <[email protected]> wrote:
| 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.
An easy way to clone a partition table is:
sfdisk -d /dev/sdX | sfdisk /dev/sdY
--
Dick Streefland //// Altium BV
[email protected] (@ @) http://www.altium.com
--------------------------------oOO--(_)--OOo---------------------------
On Tuesday 19 December 2006 15:16, Dick Streefland wrote:
> An easy way to clone a partition table is:
>
> sfdisk -d /dev/sdX | sfdisk /dev/sdY
>
And with one Maxtor 250 GB and one Seagate 250 GB, will that work? It can go
wrong on two accounts; the geometry issue I desbribed (which, I understand,
shouldn't be an issue at all), and if you're trying to clone the partition
table on a smaller disk. The latter would be fixed by leaving some unpartioned
space available.
This is something I'm going to experiment with on several disks I have.
On a sidenote, can you use this command, along with "dd if=oldpartition
of=newpartition" to clone an old disk to a new one (including NTFS/FAT
partitions for example), like Seagate disk wizzard does, and have a working
bootable system on the new disk? Or, can that even be done by dd-ing the
entire disk, and not individual partitions? I can remember G4u being
uncomfortable with that.
>Think of "PnP geometry" supported by all nowadays drives.
>
>It's 255 heads, 63 sectors per track, and whatever number of cylinders.
You do not really need the 255-63-X PNP mode. Given a hard disk small
enough, VMware may make it a 16-63-X, 16-64-X, or something like
that. Still works as intended.
You see, the kernel mostly gives a damn about CHS, since the moment
the partition table is scanned, it is translated into LBA offsets (
part of that should be seen in /proc/partitions).
-`J'
--
Wiebe Cazemier <[email protected]> wrote:
| And with one Maxtor 250 GB and one Seagate 250 GB, will that work? It can go
| wrong on two accounts; the geometry issue I desbribed (which, I understand,
| shouldn't be an issue at all), and if you're trying to clone the partition
| table on a smaller disk. The latter would be fixed by leaving some unpartioned
| space available.
Yes, that's what I usually do. I lookup the size a couple of disks of
that size, and make sure that the last partition ends before the size
of the smallest disk, by leaving some cylinders unused.
--
Dick Streefland //// Altium BV
[email protected] (@ @) http://www.altium.com
--------------------------------oOO--(_)--OOo---------------------------