* Re: [PATCH 1/2] mdmon.8: fix possible typos
From: NeilBrown @ 2011-06-28 6:38 UTC (permalink / raw)
To: Namhyung Kim; +Cc: linux-raid
In-Reply-To: <1308889610-8210-1-git-send-email-namhyung@gmail.com>
On Fri, 24 Jun 2011 13:26:49 +0900 Namhyung Kim <namhyung@gmail.com> wrote:
> Signed-off-by: Namhyung Kim <namhyung@gmail.com>
> ---
> mdmon.8 | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mdmon.8 b/mdmon.8
> index 7939a99..03b31b8 100644
> --- a/mdmon.8
> +++ b/mdmon.8
> @@ -104,7 +104,7 @@ within those disks. MD metadata in comparison defines a 1:1
> relationship between a set of block devices and a raid array. For
> example to create 2 arrays at different raid levels on a single
> set of disks, MD metadata requires the disks be partitioned and then
> -each array can created be created with a subset of those partitions. The
> +each array can be created with a subset of those partitions. The
> supported external formats perform this disk carving internally.
> .P
> Container devices simply hold references to all member disks and allow
> @@ -172,7 +172,7 @@ Note that
> is automatically started by
> .I mdadm
> when needed and so does not need to be considered when working with
> -RAID arrays. The only times it is run other that by
> +RAID arrays. The only times it is run other than by
> .I mdadm
> is when the boot scripts need to restart it after mounting the new
> root filesystem.
Thanks. I've applied both of these.
NeilBrown
^ permalink raw reply
* Re: RAID5: failing an active component during spare rebuild - arrays hangs
From: NeilBrown @ 2011-06-28 2:29 UTC (permalink / raw)
To: Alexander Lyakas; +Cc: linux-raid
In-Reply-To: <BANLkTinijekK8Y6TTk6TYtYhv4Dn2YGQbA@mail.gmail.com>
On Sun, 26 Jun 2011 21:13:17 +0300 Alexander Lyakas <alex.bolshoy@gmail.com>
wrote:
> Hello Neil,
> thank you for your response. Meanwhile I have moved to stock ubuntu
> natty 11.04, but it still happens. I have a simple script that
> reproduces the issue for me in less than 1 minute.
> System details:
> Linux ubuntu 2.6.38-8-server #42-Ubuntu SMP Mon Apr 11 03:49:04 UTC
> 2011 x86_64 x86_64 x86_64 GNU/Linux
>
> Here is the script:
> ##################################
> #!/bin/bash
>
> while true
> do
> mdadm --create /dev/md1123 --raid-devices=3 --level=5
> --bitmap=internal --name=1123 --run --auto=md --metadata=1.2
> --homehost=alex --verbose /dev/sda /dev/sdb /dev/sdc
> sleep 6
> mdadm --manage /dev/md1123 --fail /dev/sda
> sleep 1
> if mdadm --stop /dev/md1123
> then
> true
> else
> break
> fi
> done
> #####################################
Thanks for the script. Unfortunately I still cannot reproduce.
I suspect there is some subtle race issue that is heavily dependant on the
particular hardware you have.
It might help if I could get stack traces of the relevant processes. i.e.
md1123_raid5 and md1123_resync.
A previous post contained a trace of _resync, but it wouldn't hurt to get
another one. You can get them by
cat /proc/PROCESS-ID/stack
or possibly
echo w > /proc/sysrq-trigger
then look in the output of 'dmesg'.
Thanks,
NeilBrown
^ permalink raw reply
* Re: Raid auto-assembly upon boot - device order
From: Phil Turmel @ 2011-06-27 14:47 UTC (permalink / raw)
To: Pavel Hofman; +Cc: linux-raid
In-Reply-To: <4E089067.8010904@ivitera.com>
Hi Pavel,
On 06/27/2011 10:15 AM, Pavel Hofman wrote:
> Hi,
>
> We are running a raid1 on top of two raid0's. In this specific case we
> cannot use raid10 (different device sizes etc). Upon booting, the raid1
> is always started degraded, with one of the raid0's missing. The log
> says the missing raid could not be found. However, upon booting
> /proc/mdstat lists both the two raid0s OK.
>
> I guess either the raids are assembled in wrong order (no mutual
> dependencies considered), or without letting the previously assembled
> device to "settle down". I am wondering what would be the proper way to
> fix this issue. The raids are huge (over 1TB each) and recovery takes
> many hours.
>
> Our mdadm.conf lists the raids in proper order, corresponding to their
> dependency.
I would first check the copy of mdadm.conf in your initramfs. If it specifies just the raid1, you can end up in this situation.
Most distributions have an 'update-initramfs' script or something similar which must be run after any updates to files that are needed in early boot.
If this is your problem, it also explains why the raid0 appears OK after booting. The init-scripts that are available on the real root filesystem, containing the correct mdadm.conf, will assemble it.
HTH,
Phil
^ permalink raw reply
* Raid auto-assembly upon boot - device order
From: Pavel Hofman @ 2011-06-27 14:15 UTC (permalink / raw)
To: linux-raid
Hi,
We are running a raid1 on top of two raid0's. In this specific case we
cannot use raid10 (different device sizes etc). Upon booting, the raid1
is always started degraded, with one of the raid0's missing. The log
says the missing raid could not be found. However, upon booting
/proc/mdstat lists both the two raid0s OK.
I guess either the raids are assembled in wrong order (no mutual
dependencies considered), or without letting the previously assembled
device to "settle down". I am wondering what would be the proper way to
fix this issue. The raids are huge (over 1TB each) and recovery takes
many hours.
Our mdadm.conf lists the raids in proper order, corresponding to their
dependency.
Thanks a lot for any help or suggestions.
Best regards,
Pavel.
^ permalink raw reply
* Re: clarifying what can be done during resync
From: David Brown @ 2011-06-27 12:55 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <C70A636B101FD44999B82525C3E92AFAD376C7@otis.burlington.evertz.tv>
The whole point of raid is to minimize downtime - that means that if a
disk fails, you can remove it, replace it, and resync while everything
is running (albeit a bit slower).
On 27/06/2011 14:35, Sandra Escandor wrote:
> Thanks for clarifying, Neil. I actually came across this on someone's
> blog explaining how they got RAID10 (with imsm metadata) up and running,
> and he mentions that he made sure to wait until resync was done before
> mounting. I did the same thing, thinking that maybe I might break
> something if I didn't.
>
> Sandra
>
> -----Original Message-----
> From: NeilBrown [mailto:neilb@suse.de]
> Sent: Monday, June 27, 2011 1:47 AM
> To: Sandra Escandor
> Cc: linux-raid@vger.kernel.org
> Subject: Re: clarifying what can be done during resync
>
> On Thu, 23 Jun 2011 15:38:06 -0400 "Sandra Escandor"
> <sescandor@evertz.com>
> wrote:
>
>> Hello,
>>
>> Just wanted to make sure if this was a myth or not: Is it true that
> when
>> an array is in resync status, then mounting it is not at all possible?
>>
>
> Pure myth. Where did you hear it?
>
> Best approach is to try .. if it is not at all possible, then it won't
> work.
> But in fact it does :-)
>
> NeilBrown
> --
> 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
>
^ permalink raw reply
* RE: clarifying what can be done during resync
From: Sandra Escandor @ 2011-06-27 12:35 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <20110627154729.521e875a@notabene.brown>
Thanks for clarifying, Neil. I actually came across this on someone's
blog explaining how they got RAID10 (with imsm metadata) up and running,
and he mentions that he made sure to wait until resync was done before
mounting. I did the same thing, thinking that maybe I might break
something if I didn't.
Sandra
-----Original Message-----
From: NeilBrown [mailto:neilb@suse.de]
Sent: Monday, June 27, 2011 1:47 AM
To: Sandra Escandor
Cc: linux-raid@vger.kernel.org
Subject: Re: clarifying what can be done during resync
On Thu, 23 Jun 2011 15:38:06 -0400 "Sandra Escandor"
<sescandor@evertz.com>
wrote:
> Hello,
>
> Just wanted to make sure if this was a myth or not: Is it true that
when
> an array is in resync status, then mounting it is not at all possible?
>
Pure myth. Where did you hear it?
Best approach is to try .. if it is not at all possible, then it won't
work.
But in fact it does :-)
NeilBrown
^ permalink raw reply
* Re: clarifying what can be done during resync
From: NeilBrown @ 2011-06-27 5:47 UTC (permalink / raw)
To: Sandra Escandor; +Cc: linux-raid
In-Reply-To: <C70A636B101FD44999B82525C3E92AFAD374BD@otis.burlington.evertz.tv>
On Thu, 23 Jun 2011 15:38:06 -0400 "Sandra Escandor" <sescandor@evertz.com>
wrote:
> Hello,
>
> Just wanted to make sure if this was a myth or not: Is it true that when
> an array is in resync status, then mounting it is not at all possible?
>
Pure myth. Where did you hear it?
Best approach is to try .. if it is not at all possible, then it won't work.
But in fact it does :-)
NeilBrown
^ permalink raw reply
* Re: RAID5: failing an active component during spare rebuild - arrays hangs
From: Alexander Lyakas @ 2011-06-26 18:13 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <20110622125409.14428883@notabene.brown>
Hello Neil,
thank you for your response. Meanwhile I have moved to stock ubuntu
natty 11.04, but it still happens. I have a simple script that
reproduces the issue for me in less than 1 minute.
System details:
Linux ubuntu 2.6.38-8-server #42-Ubuntu SMP Mon Apr 11 03:49:04 UTC
2011 x86_64 x86_64 x86_64 GNU/Linux
Here is the script:
##################################
#!/bin/bash
while true
do
mdadm --create /dev/md1123 --raid-devices=3 --level=5
--bitmap=internal --name=1123 --run --auto=md --metadata=1.2
--homehost=alex --verbose /dev/sda /dev/sdb /dev/sdc
sleep 6
mdadm --manage /dev/md1123 --fail /dev/sda
sleep 1
if mdadm --stop /dev/md1123
then
true
else
break
fi
done
#####################################
And here is the output of one run. At the end of the output, the
--stop command fails and from that point I am unable to do anything
with the array, other than rebooting the machine.
root@ubuntu:/mnt/work/alex# ./repro.sh
mdadm: layout defaults to left-symmetric
mdadm: chunk size defaults to 512K
mdadm: layout defaults to left-symmetric
mdadm: /dev/sda appears to be part of a raid array:
level=raid5 devices=3 ctime=Sun Jun 26 20:55:54 2011
mdadm: layout defaults to left-symmetric
mdadm: /dev/sdb appears to be part of a raid array:
level=raid5 devices=3 ctime=Sun Jun 26 20:55:54 2011
mdadm: layout defaults to left-symmetric
mdadm: /dev/sdc appears to be part of a raid array:
level=raid5 devices=3 ctime=Sun Jun 26 20:55:54 2011
mdadm: size set to 20969984K
mdadm: creation continuing despite oddities due to --run
mdadm: array /dev/md1123 started.
mdadm: set /dev/sda faulty in /dev/md1123
mdadm: stopped /dev/md1123
mdadm: layout defaults to left-symmetric
mdadm: chunk size defaults to 512K
mdadm: layout defaults to left-symmetric
mdadm: /dev/sda appears to be part of a raid array:
level=raid5 devices=3 ctime=Sun Jun 26 20:57:45 2011
mdadm: layout defaults to left-symmetric
mdadm: /dev/sdb appears to be part of a raid array:
level=raid5 devices=3 ctime=Sun Jun 26 20:57:45 2011
mdadm: layout defaults to left-symmetric
mdadm: /dev/sdc appears to be part of a raid array:
level=raid5 devices=3 ctime=Sun Jun 26 20:57:45 2011
mdadm: size set to 20969984K
mdadm: creation continuing despite oddities due to --run
mdadm: array /dev/md1123 started.
mdadm: set /dev/sda faulty in /dev/md1123
mdadm: stopped /dev/md1123
mdadm: layout defaults to left-symmetric
mdadm: chunk size defaults to 512K
mdadm: layout defaults to left-symmetric
mdadm: /dev/sda appears to be part of a raid array:
level=raid5 devices=3 ctime=Sun Jun 26 20:57:52 2011
mdadm: layout defaults to left-symmetric
mdadm: /dev/sdb appears to be part of a raid array:
level=raid5 devices=3 ctime=Sun Jun 26 20:57:52 2011
mdadm: layout defaults to left-symmetric
mdadm: /dev/sdc appears to be part of a raid array:
level=raid5 devices=3 ctime=Sun Jun 26 20:57:52 2011
mdadm: size set to 20969984K
mdadm: creation continuing despite oddities due to --run
mdadm: array /dev/md1123 started.
mdadm: set /dev/sda faulty in /dev/md1123
mdadm: failed to stop array /dev/md1123: Device or resource busy
Perhaps a running process, mounted filesystem or active volume group?
At this point mdadm --detail produces:
/dev/md1123:
Version : 1.2
Creation Time : Sun Jun 26 20:57:59 2011
Raid Level : raid5
Array Size : 41939968 (40.00 GiB 42.95 GB)
Used Dev Size : 20969984 (20.00 GiB 21.47 GB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Sun Jun 26 20:58:23 2011
State : active, FAILED
Active Devices : 1
Working Devices : 2
Failed Devices : 1
Spare Devices : 1
Layout : left-symmetric
Chunk Size : 512K
Name : alex:1123
UUID : cd564563:94fecf52:5b3492d4:4530ecbc
Events : 4
Number Major Minor RaidDevice State
0 8 0 0 faulty spare rebuilding /dev/sda
1 8 16 1 active sync /dev/sdb
3 8 32 2 spare rebuilding /dev/sdc
and the faulty device is not kicked out from the array, as I would expect.
Thanks,
Alex.
On Wed, Jun 22, 2011 at 5:54 AM, NeilBrown <neilb@suse.de> wrote:
>
> On Sun, 5 Jun 2011 22:41:55 +0300 Alexander Lyakas <alex.bolshoy@gmail.com>
> wrote:
>
> > Hello everybody,
> > I am testing a scenario, in which I create a RAID5 with three devices:
> > /dev/sd{a,b,c}. Since I don't supply --force to mdadm during creation,
> > it treats the array as degraded and starts rebuilding the sdc as a
> > spare. This is as documented.
> >
> > Then I do --fail on /dev/sda. I understand that at this point my data
> > is gone, but I think should still be able to tear down the array.
> >
> > Sometimes I see that /dev/sda is kicked from the array as faulty, and
> > /dev/sdc is also removed and marked as a spare. Then I am able to tear
> > down the array.
> >
> > But sometimes, it looks like the system hits some kind of a deadlock.
>
> I cannot reproduce this, either on current mainline or 2.6.38. I didn't try
> the particular Ubuntu kernel that you mentioned as I don't have any Ubuntu
> machines.
> It is unlikely that Ubuntu have broken something, but not impossible... are
> you able to compile a kernel.org kernel (preferably 2.6.39) and see if you
> can reproduce.
>
> Also, can you provide a simple script that will trigger the bug reliably for
> you.
>
> I did:
>
> while : ; do mdadm -CR /dev/md0 -l5 -n3 /dev/sd[abc] ; sleep 5; mdadm /dev/md0 -f /dev/sda ; mdadm -Ss ; echo ; echo; done
>
> and it has no problems at all.
>
> Certainly a deadlock shouldn't be happening...
>
> From the stack trace you get it looks like it is probably hanging at
>
> wait_event(mddev->recovery_wait, !atomic_read(&mddev->recovery_active));
>
> which suggests that so resync request started and didn't complete. I've
> never seen a hang there before.
>
> NeilBrown
>
--
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
^ permalink raw reply
* [PATCH resend 3/6] md: use proper little-endian bitops
From: Akinobu Mita @ 2011-06-26 5:57 UTC (permalink / raw)
To: linux-kernel, akpm; +Cc: Akinobu Mita, NeilBrown, linux-raid
In-Reply-To: <1309067876-3537-1-git-send-email-akinobu.mita@gmail.com>
Using __test_and_{set,clear}_bit_le() with ignoring its return value
can be replaced with __{set,clear}_bit_le().
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: NeilBrown <neilb@suse.de>
Cc: linux-raid@vger.kernel.org
---
drivers/md/bitmap.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/md/bitmap.c b/drivers/md/bitmap.c
index 574b09a..870a7fc 100644
--- a/drivers/md/bitmap.c
+++ b/drivers/md/bitmap.c
@@ -932,7 +932,7 @@ static void bitmap_file_set_bit(struct bitmap *bitmap, sector_t block)
if (bitmap->flags & BITMAP_HOSTENDIAN)
set_bit(bit, kaddr);
else
- __test_and_set_bit_le(bit, kaddr);
+ __set_bit_le(bit, kaddr);
kunmap_atomic(kaddr, KM_USER0);
PRINTK("set file bit %lu page %lu\n", bit, page->index);
}
@@ -1304,7 +1304,7 @@ void bitmap_daemon_work(mddev_t *mddev)
clear_bit(file_page_offset(bitmap, j),
paddr);
else
- __test_and_clear_bit_le(file_page_offset(bitmap, j),
+ __clear_bit_le(file_page_offset(bitmap, j),
paddr);
kunmap_atomic(paddr, KM_USER0);
} else
--
1.7.4.4
^ permalink raw reply related
* [PATCH resend 0/6] use little-endian bitops properly
From: Akinobu Mita @ 2011-06-26 5:57 UTC (permalink / raw)
To: linux-kernel, akpm
Cc: Akinobu Mita, Theodore Ts'o, Andreas Dilger, linux-ext4,
Alasdair Kergon, dm-devel, NeilBrown, linux-raid, reiserfs-devel,
Joel Becker, Mark Fasheh, ocfs2-devel
All patches in this patch set were sent before. Individual patches
improve little-endian bitops usage in several places.
Akinobu Mita (6):
ext4: use proper little-endian bitops
dm: use use proper little-endian bitops
md: use proper little-endian bitops
reiserfs: use proper little-endian bitops
reiserfs: use hweight_long()
ocfs2: avoid unaligned access to dqc_bitmap
drivers/md/bitmap.c | 4 +-
drivers/md/dm-log.c | 9 +++----
fs/ext4/ext4.h | 7 +++--
fs/ext4/ialloc.c | 4 +-
fs/ocfs2/ocfs2.h | 47 +++++++++++++++++++++++++++++++++++++++++++
fs/ocfs2/quota_local.c | 10 ++++----
fs/reiserfs/bitmap.c | 8 +-----
fs/reiserfs/resize.c | 6 ++--
include/linux/reiserfs_fs.h | 2 +
9 files changed, 71 insertions(+), 26 deletions(-)
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Andreas Dilger <adilger.kernel@dilger.ca>
Cc: linux-ext4@vger.kernel.org
Cc: Alasdair Kergon <agk@redhat.com>
Cc: dm-devel@redhat.com
Cc: NeilBrown <neilb@suse.de>
Cc: linux-raid@vger.kernel.org
Cc: reiserfs-devel@vger.kernel.org
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Mark Fasheh <mfasheh@suse.com>
Cc: ocfs2-devel@oss.oracle.com
--
1.7.4.4
^ permalink raw reply
* Re: raid upgrade form 1.5T to 3T drives with 0.90 superblock
From: Stan Hoeppner @ 2011-06-25 0:15 UTC (permalink / raw)
To: Krzysztof Adamski; +Cc: linux-raid
In-Reply-To: <1308918217.23175.85.camel@oxygen.netxsys.com>
On 6/24/2011 7:23 AM, Krzysztof Adamski wrote:
> On Fri, 2011-06-24 at 00:35 -0500, Stan Hoeppner wrote:
>> On 6/23/2011 1:43 PM, Krzysztof Adamski wrote:
>>> Hi All,
>>>
>>> I have a raid6 array made out of 8 1.5T drives and I wanted to change to
>>> use 3T drives. The array is 0.90. After reading the wiki I see that 0.90
>>> superblock will not work with any device larger then 2T.
>>>
>>> What are my options for a live upgrade (backup/restore is not possible)?
>>
>> The best way to do this, given that you have no backup, is to add a
>> known-to-work-with-Linux SAS/SATA HBA and build a new md array and
>> format it with a fresh filesystem. Let the 8 new drives spin for a
>> couple of days. If all 8 drives are still kicking, copy everything over
>> from the current filesystem with a 'cp -a' or similar method. If you
>> have NFS/Samba shares or other filesystem specific mappings, rsync, etc,
>> edit your conf files to point to the new filesystem/device. Run in
>> production with the new array for a few days or a week to make sure it's
>> working correctly, then remove the old array at your leisure.
>
> I was afraid of this. I only have 4 empty drive bays in my Norco 4220
> case, I will have to shut down the second array and remove it during the
> time I'm upgrading. I will also have to get an HBA that supports 3T
> drives.
>
>> This staged multi step approach gives you the best chance to avoid data
>> loss during the migration as even after it's complete you still have the
>> existing array fully intact until you decide to remove it. It is much
>> safer than rebuilding an 8 disk array one disk at a time. It also puts
>> much less wear and tear on the new drives. Another benefit is that
>> after copying the files over, the new filesystem will be much less
>> fragmented than in the case of rebuilding the existing array one drive
>> at a time.
>
> I have before upgrade a 5 drive array one drive at a time without
> problems, but the new drives were only 2T.
>
>> If you don't have 16 disk bays and sufficient SAS/SATA ports in your
>> current chassis, and you can't leave a side panel off with the 8 new
>> drives simply sitting on a desk during the transition, then you should
>> grab an external enclosure, either desktop or rackmount, whichever fits
>> your needs, and an external version of the HBA. Some options are:
>>
>> If you have 16 bays or can sit the new 8 drives on the desk next to the
>> server during the upgrade just grab one of these cheap LSI based Intel 8
>> port HBAs:
>>
>> http://www.newegg.com/Product/Product.aspx?Item=N82E16816117157
>
> This card is based on 1068E chip, it does not support drives larger then
> 2T. I already have 2 LSI cards based on the same chip and I will need to
> upgrade.
Good point. Sorry for the oversight. Now knowing that you have the 20
bay 4220 chassis, I'd suggest moving to a single LSI PCIe 2.0 x8 6Gb/s
HBA and an Intel SAS expander, to control all 20 bays and allowing 3TB
drives in all bays.
http://www.lsi.com/products/storagecomponents/Pages/MegaRAIDSAS9240-4i.aspx
http://www.intel.com/Products/Server/RAID-controllers/re-res2sv240/RES2SV240-Overview.htm
You can power the expander via the PCIe x4 edge connector or via a
standard 4 pin Molex PSU power plug if you mount the expander PCB to the
side or floor of the chassis with stand offs, which is the method I use
to save all my PCIe slots.
This combo will give you 2.4GB/s (4.8 bidirectional) throughput to all
20 bays, or 120MB/s per drive. You plug one SFF8087 from the HBA into
the expander and 5 such cables from the expander to each backplane. You
probably already have all the cables you need but for the HBA to
expander cable.
After transitioning the system from the current HBAs to the new single
HBA and expander, and verifying functionality, add 4 of your eight 3TB
drives to the 4 empty bays. Create an md RAID5 array of the 4 disks and
create your filesystem. You will have ~9TB usable space, about the same
as your eight 1.5TB drive RAID6. Copy all files over to the new array
as previously discussed, verify functionality.
Now take the existing eight 1.5TB drive RAID6 array offline. Pull all 8
drives of that array from the chassis. Insert the remaining four 3TB
drives and reshape the new RAID5 array to include the 4 new disks. I'm
not sure if you can reshape with the new drives straight to RAID6 at
this point in one step. If it's possible do so, go for it. If not,
reshape the RAID5 with the new drives, and when that completes
successfully then reshape again to RAID6.
If anything goes wrong, you still have the original 8 1.5TB drives
stashed in a cabinet somewhere if you need to revert back.
Hope this was helpful.
--
Stan
^ permalink raw reply
* Re: raid upgrade form 1.5T to 3T drives with 0.90 superblock
From: NeilBrown @ 2011-06-24 22:00 UTC (permalink / raw)
To: Krzysztof Adamski; +Cc: linux-raid
In-Reply-To: <1308854595.23175.65.camel@oxygen.netxsys.com>
On Thu, 23 Jun 2011 14:43:15 -0400 Krzysztof Adamski <k@adamski.org> wrote:
> Hi All,
>
> I have a raid6 array made out of 8 1.5T drives and I wanted to change to
> use 3T drives. The array is 0.90. After reading the wiki I see that 0.90
> superblock will not work with any device larger then 2T.
>
> What are my options for a live upgrade (backup/restore is not possible)?
>
I really am going to have to add --update=metadata to mdadm one day...
Simply stop the array and create it again with --metadata=1.0.
For safety specify all the details : chunk size, layout, raid-disks, as the
defaults might have changed.
Create the array 'assume-clean' to it doesn't try to resync. Then check
(read-only) that your data is good.
e.g.
mdadm -S /dev/md0
mdadm -C /dev/md0 -l6 -n8 -c64 --layout=la --assume-clean \
/dev/sda1 /dev/sdb1 /dev/sdc1 ....
You should specify --size as well ... otherwise mdadm might leave too much
space for a bitmap - I don't remember exactly.
Make sure you put the device names in the correct order. You can find this
order from "mdadm -D".
If you like you could post the output of mdadm -D and the commands you
propose to run so I/others can verify it for you.
1.0 metadata puts the metadata at the end just like 0.90, and the metadata is
smaller so the data will remain untouched.
Just this create command by itself cannot destroy you data so if you then
look at the array read-only it will still not change anything. Once you are
sure everything is OK you can start writing.
Oh, and of course do all this with the 1.5 drives. Don't try adding the 3T
drives until verything is stable.
Good luck,
NeilBrown
^ permalink raw reply
* [smatch stuff] md/raid5: potential null deref in debug code
From: Dan Carpenter @ 2011-06-24 18:12 UTC (permalink / raw)
To: neilb; +Cc: linux-raid
Hi Neil,
In d1b053e4de0ac33 "md/raid5: Protect some more code with
->device_lock." we moved some debug code around and it upsets my
static checker. Could you take a look?
drivers/md/raid5.c +2183 add_stripe_bio(47)
error: potential null derefence 'bi'.
2168 if (forwrite) {
2169 /* check if page is covered */
2170 sector_t sector = sh->dev[dd_idx].sector;
2171 for (bi=sh->dev[dd_idx].towrite;
2172 sector < sh->dev[dd_idx].sector + STRIPE_SECTORS &&
2173 bi && bi->bi_sector <= sector;
^^
It looks like "bi" can be NULL at the end of this for loop.
2174 bi = r5_next_bio(bi, sh->dev[dd_idx].sector)) {
2175 if (bi->bi_sector + (bi->bi_size>>9) >= sector)
2176 sector = bi->bi_sector + (bi->bi_size>>9);
2177 }
2178 if (sector >= sh->dev[dd_idx].sector + STRIPE_SECTORS)
2179 set_bit(R5_OVERWRITE, &sh->dev[dd_idx].flags);
2180 }
2181 spin_unlock_irq(&conf->device_lock);
2182
2183 pr_debug("added bi b#%llu to stripe s#%llu, disk %d.\n",
2184 (unsigned long long)bi->bi_sector,
^^^^^^^^^^^^^
We dereference it here.
2185 (unsigned long long)sh->sector, dd_idx);
regards,
dan carpenter
^ permalink raw reply
* Re: Looking for the best way to do this
From: maurice @ 2011-06-24 17:11 UTC (permalink / raw)
Cc: linux-raid
In-Reply-To: <4E04C27E.7040608@cdf.toronto.edu>
On 6/24/2011 10:59 AM, Iordan Iordanov wrote:
>
> On 06/24/11 12:35, maurice wrote:
>> Set aside (disconnect) 1 of the existing 2 disks.
>> Boot from emergency recovery media, making sure the md version is
>> relatively current ( newer than 3.0 ?)
>>
>> Create the R10 with the other 2 disks ( 1 old and 1 new) with 1 of the 3
>> disks missing.
>> I think I have to wipe the superblock on the disk that was formerly part
>> of the RAID1 set.
>
> I think your procedure can be made less risky by making a R10, with
> layout f3 with *two* missing disks. Since there are *3* copies in the
> R10, there is no problem with having just one "real" disk and two
> missing ones. This way, you don't have to live with just one of the R1
> disks and hope it doesn't go bad during the copy operation.
>
> Then, you copy the data from your old R1 to your new R10 with the two
> missing disks. When the data is copied over, you can remove *one* of
> the disks from the R1, zero the superblock, and add it to the R10.
> When the rebuild is complete, and only then, zero the superblock of
> your last R1 disk, and add it to the R10.
>
> With this mod, your data never really lost redundancy during the
> entire procedure (except when you remove the first disk from the R1
> and move it to the R10, but instead of redundancy, you have 2 copies -
> one on the R10 and one on the R1 at that point, so it's still
> redundant in a way).
>
> Whether or not you use this revised procedure, write yourself a
> step-by-step guide with all the commands (a TO-DO list), and if you
> want, you can share it with the list if you're not confident.
>
Thanks, this makes really good sense, and sounds VERY safe.
As for the "TO-DO list" or "recipe" I still lack the skills to produce
the syntax.
--
Cheers,
Maurice Hilarius
eMail: /mhilarius@gmail.com/
^ permalink raw reply
* Re: Looking for the best way to do this
From: Iordan Iordanov @ 2011-06-24 16:59 UTC (permalink / raw)
To: maurice; +Cc: linux-raid
In-Reply-To: <4E04BCCF.9000604@gmail.com>
Hi Maurice,
On 06/24/11 12:35, maurice wrote:
> Set aside (disconnect) 1 of the existing 2 disks.
> Boot from emergency recovery media, making sure the md version is
> relatively current ( newer than 3.0 ?)
>
> Create the R10 with the other 2 disks ( 1 old and 1 new) with 1 of the 3
> disks missing.
> I think I have to wipe the superblock on the disk that was formerly part
> of the RAID1 set.
I think your procedure can be made less risky by making a R10, with
layout f3 with *two* missing disks. Since there are *3* copies in the
R10, there is no problem with having just one "real" disk and two
missing ones. This way, you don't have to live with just one of the R1
disks and hope it doesn't go bad during the copy operation.
Then, you copy the data from your old R1 to your new R10 with the two
missing disks. When the data is copied over, you can remove *one* of the
disks from the R1, zero the superblock, and add it to the R10. When the
rebuild is complete, and only then, zero the superblock of your last R1
disk, and add it to the R10.
With this mod, your data never really lost redundancy during the entire
procedure (except when you remove the first disk from the R1 and move it
to the R10, but instead of redundancy, you have 2 copies - one on the
R10 and one on the R1 at that point, so it's still redundant in a way).
Whether or not you use this revised procedure, write yourself a
step-by-step guide with all the commands (a TO-DO list), and if you
want, you can share it with the list if you're not confident.
Cheers,
Iordan
^ permalink raw reply
* Re: Looking for the best way to do this
From: maurice @ 2011-06-24 16:35 UTC (permalink / raw)
To: Iordan Iordanov; +Cc: maurice, linux-raid
In-Reply-To: <4E04B8A9.1050502@cdf.toronto.edu>
On 6/24/2011 10:17 AM, Iordan Iordanov wrote:
> Hi Maurice,
> ..
> R10 has different layouts. There are two components to the layout -
> where the chunks are located on the different devices (near, offset,
> far), and number of copies of the data. The near/offset/far part of
> the layout does not play a role in reliability, just in performance.
> So, the number of copies is the only thing that matters to this
> discussion.
>
> If you have R10 with 3 disks and 3 copies, it is equally reliable to
> R1 with 3 disks, as they have an equal number of copies. In both R10
> and R1 in this case, two disks can fail, and you still have 1 intact
> copy remaining.
>
From what I read, assuming I want to optimize this for READ
performance, I would want "R10 far".
As I understand this, if I wanted the R10, I could set aside one disk of
the R1 with my existing data,
and use on of the old disks, along with the new one, to create the R10 ?
I believe the way to accomplish this is as follows:
Set aside (disconnect) 1 of the existing 2 disks.
Boot from emergency recovery media, making sure the md version is
relatively current ( newer than 3.0 ?)
Create the R10 with the other 2 disks ( 1 old and 1 new) with 1 of the 3
disks missing.
I think I have to wipe the superblock on the disk that was formerly part
of the RAID1 set.
Reconnect the old R1 reserved disk.
Copy the data from the single member of the old R1 to the new R10
On the old disk of the R1 set wipe the superblock.
Lastly add the 3rd disk to the R10 set.
Run grub to put the boot block on all 3 of the disks.
Assuming that this sequence is correct, what I need now is the correct
syntx for these steps.
Or, perhaps, I have it wrong!
--
Cheers,
Maurice Hilarius
eMail: /mhilarius@gmail.com/
^ permalink raw reply
* Re: Looking for the best way to do this
From: Iordan Iordanov @ 2011-06-24 16:17 UTC (permalink / raw)
To: maurice; +Cc: linux-raid
In-Reply-To: <4E03B8DB.7010607@gmail.com>
Hi Maurice,
On 06/23/11 18:06, maurice wrote:
> What I do NOT know is the following:
> A) Which is more RELIABLE: R1 with 3 disks or R10 with 3 disks.
R10 has different layouts. There are two components to the layout -
where the chunks are located on the different devices (near, offset,
far), and number of copies of the data. The near/offset/far part of the
layout does not play a role in reliability, just in performance. So, the
number of copies is the only thing that matters to this discussion.
If you have R10 with 3 disks and 3 copies, it is equally reliable to R1
with 3 disks, as they have an equal number of copies. In both R10 and R1
in this case, two disks can fail, and you still have 1 intact copy
remaining.
> B) HOW to create either the 3 disk R1 or R10, assuming an existing 2
> disk R1.
If there is an existing R1, and you just want to add an extra device to
it, it's easy - you just have to "grow" the array to increase the number
of devices, and then "add" a device, and it'll become a 3 device R1. I
don't think you'd want to switch to R10 if you are looking to just add a
3rd device to an existing R1!
Example:
mdadm --grow -n 3 /dev/md0
mdadm /dev/md0 --add /dev/sdc1
Does that help?
Cheers,
Iordan
^ permalink raw reply
* Re: raid upgrade form 1.5T to 3T drives with 0.90 superblock
From: Krzysztof Adamski @ 2011-06-24 12:23 UTC (permalink / raw)
To: Stan Hoeppner; +Cc: linux-raid
In-Reply-To: <4E04220E.3080201@hardwarefreak.com>
On Fri, 2011-06-24 at 00:35 -0500, Stan Hoeppner wrote:
> On 6/23/2011 1:43 PM, Krzysztof Adamski wrote:
> > Hi All,
> >
> > I have a raid6 array made out of 8 1.5T drives and I wanted to change to
> > use 3T drives. The array is 0.90. After reading the wiki I see that 0.90
> > superblock will not work with any device larger then 2T.
> >
> > What are my options for a live upgrade (backup/restore is not possible)?
>
> The best way to do this, given that you have no backup, is to add a
> known-to-work-with-Linux SAS/SATA HBA and build a new md array and
> format it with a fresh filesystem. Let the 8 new drives spin for a
> couple of days. If all 8 drives are still kicking, copy everything over
> from the current filesystem with a 'cp -a' or similar method. If you
> have NFS/Samba shares or other filesystem specific mappings, rsync, etc,
> edit your conf files to point to the new filesystem/device. Run in
> production with the new array for a few days or a week to make sure it's
> working correctly, then remove the old array at your leisure.
I was afraid of this. I only have 4 empty drive bays in my Norco 4220
case, I will have to shut down the second array and remove it during the
time I'm upgrading. I will also have to get an HBA that supports 3T
drives.
> This staged multi step approach gives you the best chance to avoid data
> loss during the migration as even after it's complete you still have the
> existing array fully intact until you decide to remove it. It is much
> safer than rebuilding an 8 disk array one disk at a time. It also puts
> much less wear and tear on the new drives. Another benefit is that
> after copying the files over, the new filesystem will be much less
> fragmented than in the case of rebuilding the existing array one drive
> at a time.
I have before upgrade a 5 drive array one drive at a time without
problems, but the new drives were only 2T.
> If you don't have 16 disk bays and sufficient SAS/SATA ports in your
> current chassis, and you can't leave a side panel off with the 8 new
> drives simply sitting on a desk during the transition, then you should
> grab an external enclosure, either desktop or rackmount, whichever fits
> your needs, and an external version of the HBA. Some options are:
>
> If you have 16 bays or can sit the new 8 drives on the desk next to the
> server during the upgrade just grab one of these cheap LSI based Intel 8
> port HBAs:
>
> http://www.newegg.com/Product/Product.aspx?Item=N82E16816117157
This card is based on 1068E chip, it does not support drives larger then
2T. I already have 2 LSI cards based on the same chip and I will need to
upgrade.
>
> If you must go external, take a look at these. A bit more costly, but a
> better solution in the long run. It'll also allow you to keep your
> existing array instead of replacing it. If you go with the rackmount
> unit adding a 4 port HBA in the future will allow you to add 4 more
> drives. Each row of 4 drives has its own SFF8088 port on the back.
>
> http://www.newegg.com/Product/Product.aspx?Item=N82E16816118116
> http://www.newegg.com/Product/Product.aspx?Item=N82E16816111092
> http://www.newegg.com/Product/Product.aspx?Item=N82E16816133044
>
^ permalink raw reply
* Re: raid upgrade form 1.5T to 3T drives with 0.90 superblock
From: Stan Hoeppner @ 2011-06-24 5:35 UTC (permalink / raw)
To: Krzysztof Adamski; +Cc: linux-raid
In-Reply-To: <1308854595.23175.65.camel@oxygen.netxsys.com>
On 6/23/2011 1:43 PM, Krzysztof Adamski wrote:
> Hi All,
>
> I have a raid6 array made out of 8 1.5T drives and I wanted to change to
> use 3T drives. The array is 0.90. After reading the wiki I see that 0.90
> superblock will not work with any device larger then 2T.
>
> What are my options for a live upgrade (backup/restore is not possible)?
The best way to do this, given that you have no backup, is to add a
known-to-work-with-Linux SAS/SATA HBA and build a new md array and
format it with a fresh filesystem. Let the 8 new drives spin for a
couple of days. If all 8 drives are still kicking, copy everything over
from the current filesystem with a 'cp -a' or similar method. If you
have NFS/Samba shares or other filesystem specific mappings, rsync, etc,
edit your conf files to point to the new filesystem/device. Run in
production with the new array for a few days or a week to make sure it's
working correctly, then remove the old array at your leisure.
This staged multi step approach gives you the best chance to avoid data
loss during the migration as even after it's complete you still have the
existing array fully intact until you decide to remove it. It is much
safer than rebuilding an 8 disk array one disk at a time. It also puts
much less wear and tear on the new drives. Another benefit is that
after copying the files over, the new filesystem will be much less
fragmented than in the case of rebuilding the existing array one drive
at a time.
If you don't have 16 disk bays and sufficient SAS/SATA ports in your
current chassis, and you can't leave a side panel off with the 8 new
drives simply sitting on a desk during the transition, then you should
grab an external enclosure, either desktop or rackmount, whichever fits
your needs, and an external version of the HBA. Some options are:
If you have 16 bays or can sit the new 8 drives on the desk next to the
server during the upgrade just grab one of these cheap LSI based Intel 8
port HBAs:
http://www.newegg.com/Product/Product.aspx?Item=N82E16816117157
If you must go external, take a look at these. A bit more costly, but a
better solution in the long run. It'll also allow you to keep your
existing array instead of replacing it. If you go with the rackmount
unit adding a 4 port HBA in the future will allow you to add 4 more
drives. Each row of 4 drives has its own SFF8088 port on the back.
http://www.newegg.com/Product/Product.aspx?Item=N82E16816118116
http://www.newegg.com/Product/Product.aspx?Item=N82E16816111092
http://www.newegg.com/Product/Product.aspx?Item=N82E16816133044
--
Stan
^ permalink raw reply
* [PATCH] md/raid5: fix possible NULL pointer dereference in debug routine
From: Namhyung Kim @ 2011-06-24 5:04 UTC (permalink / raw)
To: Neil Brown; +Cc: linux-raid, linux-kernel
When I ran dynamic debug, I encountered a NULL pointer dereference
bug in add_stripe_bio(). Prior to second call to pr_debug(), @bi
was reused in order to check whether the request is partial write
or not, and it could lead to set @bi to NULL.
Since we save original @bi pointer into local variable 'bip', use
it instead of NULL-able @bi.
Also changed confusing 'bh' to 'bi' in the first message.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
---
drivers/md/raid5.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 82c07fb38961..c814a6075c79 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -2139,7 +2139,7 @@ static int add_stripe_bio(struct stripe_head *sh, struct bio *bi, int dd_idx, in
raid5_conf_t *conf = sh->raid_conf;
int firstwrite=0;
- pr_debug("adding bh b#%llu to stripe s#%llu\n",
+ pr_debug("adding bi b#%llu to stripe s#%llu\n",
(unsigned long long)bi->bi_sector,
(unsigned long long)sh->sector);
@@ -2181,7 +2181,7 @@ static int add_stripe_bio(struct stripe_head *sh, struct bio *bi, int dd_idx, in
spin_unlock_irq(&conf->device_lock);
pr_debug("added bi b#%llu to stripe s#%llu, disk %d.\n",
- (unsigned long long)bi->bi_sector,
+ (unsigned long long)(*bip)->bi_sector,
(unsigned long long)sh->sector, dd_idx);
if (conf->mddev->bitmap && firstwrite) {
--
1.7.5.2
^ permalink raw reply related
* [PATCH 2/2] md.4: fix possible typos
From: Namhyung Kim @ 2011-06-24 4:26 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <1308889610-8210-1-git-send-email-namhyung@gmail.com>
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
---
md.4 | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/md.4 b/md.4
index 5e79639..378ecc9 100644
--- a/md.4
+++ b/md.4
@@ -128,7 +128,7 @@ have special-purpose uses and is supported.
From release 2.6.28, the
.I md
driver supports arrays with externally managed metadata. That is,
-the metadata is not managed by the kernel by rather by a user-space
+the metadata is not managed by the kernel but rather by a user-space
program which is external to the kernel. This allows support for a
variety of metadata formats without cluttering the kernel with lots of
details.
@@ -468,7 +468,7 @@ scrub starts and is incremented whenever a sector is
found that is a mismatch.
.I md
normally works in units much larger than a single sector and when it
-finds a mismatch, it does not determin exactly how many actual sectors were
+finds a mismatch, it does not determine exactly how many actual sectors were
affected but simply adds the number of sectors in the IO unit that was
used. So a value of 128 could simply mean that a single 64KB check
found an error (128 x 512bytes = 64KB).
@@ -661,7 +661,7 @@ to this file will cause the system-wide setting to have effect.
This is the partner of
.B md/sync_speed_min
and overrides
-.B /proc/sys/dev/raid/spool_limit_max
+.B /proc/sys/dev/raid/speed_limit_max
described below.
.TP
--
1.7.5.2
^ permalink raw reply related
* [PATCH 1/2] mdmon.8: fix possible typos
From: Namhyung Kim @ 2011-06-24 4:26 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
---
mdmon.8 | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/mdmon.8 b/mdmon.8
index 7939a99..03b31b8 100644
--- a/mdmon.8
+++ b/mdmon.8
@@ -104,7 +104,7 @@ within those disks. MD metadata in comparison defines a 1:1
relationship between a set of block devices and a raid array. For
example to create 2 arrays at different raid levels on a single
set of disks, MD metadata requires the disks be partitioned and then
-each array can created be created with a subset of those partitions. The
+each array can be created with a subset of those partitions. The
supported external formats perform this disk carving internally.
.P
Container devices simply hold references to all member disks and allow
@@ -172,7 +172,7 @@ Note that
is automatically started by
.I mdadm
when needed and so does not need to be considered when working with
-RAID arrays. The only times it is run other that by
+RAID arrays. The only times it is run other than by
.I mdadm
is when the boot scripts need to restart it after mounting the new
root filesystem.
--
1.7.5.2
^ permalink raw reply related
* Re: Looking for the best way to do this
From: Phil Turmel @ 2011-06-23 23:41 UTC (permalink / raw)
To: maurice; +Cc: linux-raid@vger.kernel.org
In-Reply-To: <4E03CBC3.1080001@gmail.com>
Hi Maurice,
[restored CC list.... use reply-to-all on kernel.org lists]
On 06/23/2011 07:26 PM, maurice wrote:
> On 6/23/2011 4:55 PM, Phil Turmel wrote:
>> Hi maurice,
>
> Hi Phil
>
> That was great, thank you!
>
> I gather that the R10 results ion a faster disk IO, in general?
> Probably with the "far" version, if we are mostly reading?
For most applications, yes. I haven't benchmarked it myself, though.
> I would be willing to lose redundancy for the duration of the creation process.
> Both disks presently seem to be OK.
You'll also be offline while copying and switching to the new filesystem. Did you want layout=f2 or =f3 ?
> Any chance you could "wrap up" for me with the correct syntax for this?
> I find that the "trial and error " approach is less than optimal.
First, run a check on your array, to minimize the chance of a read error during the copy:
echo "check" >/sys/block/md*/md/sync_action
While that's running, send me the output of "lsdrv", which will let me give advice with real device names:
wget -O /usr/sbin/lsdrv http://github.com/pturmel/lsdrv/raw/master/lsdrv ; chmod 755 /usr/sbin/lsdrv ; lsdrv
Phil
^ permalink raw reply
* Re: Looking for the best way to do this
From: Phil Turmel @ 2011-06-23 22:55 UTC (permalink / raw)
To: maurice; +Cc: Iordan Iordanov, linux-raid
In-Reply-To: <4E03B8DB.7010607@gmail.com>
Hi maurice,
On 06/23/2011 06:06 PM, maurice wrote:
> On 6/23/2011 1:23 PM, Iordan Iordanov wrote:
>> Hi Maurice,
>>
>> On 06/21/11 14:13, maurice wrote:
>>> Add 3rd disk to make a 3 disk RAID1
>>> Make a RAID10, missing one disk.
>>
>> Perhaps I misunderstand your supposition, and if I do, please correct me. RAID10 with mdadm does not require a minimum of 4 disks.
> Yes, that was my understanding.
>
>> For example, mdadm can do RAID10 with 2 copies on 3 disks or RAID10 with 3 copies on 3 disks, yielding the equivalent of RAID1 in terms of data security. It is not confined to mirroring two pairs of disks and then striping across them as is the "conventional" way of doing RAID10.
> Yes, I understand the principle.
>>
>> You can read the man-page of mdadm, where the options for "layout" of RAID10 are discussed. Pay particular attention to the end of the "--layout" option explanation.
>
> What I do NOT know is the following:
> A) Which is more RELIABLE: R1 with 3 disks or R10 with 3 disks.
R1 with 3 disks is three copies of all sectors. R10 with three disks can be either two copies of each sector or three copies. A two-copy layout would have capacity equal to 1.5 * the member disk size. For reliability, three copies is better than two copies. R10 and R1 use different algorithms, so you will have different performance pros and cons.
> B) HOW to create either the 3 disk R1 or R10, assuming an existing 2 disk R1.
You can "--grow" the number of disks (copies) in an R1 while running. R10 does not (yet) support layout or capacity changes, whether running or not. So if you want R10, you'll have to start from scratch.
If you are willing to give up your redundancy temporarily, you could create a degraded R10 from the new drive and one of the existing drives, copy the partition from the remaining drive in the R1, stop and destroy the R1, then add that disk into the R10.
Phil
^ permalink raw reply
* Re: Looking for the best way to do this
From: maurice @ 2011-06-23 22:06 UTC (permalink / raw)
To: Iordan Iordanov; +Cc: linux-raid
In-Reply-To: <4E03929A.8000503@cdf.toronto.edu>
On 6/23/2011 1:23 PM, Iordan Iordanov wrote:
> Hi Maurice,
>
> On 06/21/11 14:13, maurice wrote:
>> Add 3rd disk to make a 3 disk RAID1
>> Make a RAID10, missing one disk.
>
> Perhaps I misunderstand your supposition, and if I do, please correct
> me. RAID10 with mdadm does not require a minimum of 4 disks.
Yes, that was my understanding.
> For example, mdadm can do RAID10 with 2 copies on 3 disks or RAID10
> with 3 copies on 3 disks, yielding the equivalent of RAID1 in terms of
> data security. It is not confined to mirroring two pairs of disks and
> then striping across them as is the "conventional" way of doing RAID10.
Yes, I understand the principle.
>
> You can read the man-page of mdadm, where the options for "layout" of
> RAID10 are discussed. Pay particular attention to the end of the
> "--layout" option explanation.
What I do NOT know is the following:
A) Which is more RELIABLE: R1 with 3 disks or R10 with 3 disks.
B) HOW to create either the 3 disk R1 or R10, assuming an existing 2
disk R1.
--
Cheers,
Maurice Hilarius
eMail: /mhilarius@gmail.com/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox