From: Bill Cronk <ngc4013@cox.net>
To: linux-raid@vger.kernel.org
Cc: neilb@cse.unsw.edu.au
Subject: Question regarding mdadm and RAID boxes
Date: Sun, 31 Oct 2004 21:32:40 -0500 [thread overview]
Message-ID: <4185A048.1070308@cox.net> (raw)
I recently have had the pleasure to start using mdadm. Previously I was
using the old raidtools and creating a raidtab file to reflect the
current configuration requirements for the attached RAID boxes. Since at
work I have had to use Redhat only on my computers, I have been using
RH-9 with the intention of migrating up to FC2 or FC3 when stable. So I
started using FC2 and tried moving my RAID boxes over which gave me some
problems, but after some discussions with co-workers and a question
being answered on the fedora-list group, I decided to apply the hard
drive flag 'fd' and then move over to using mdadm only to manage my RAID
boxes.
So this is where the real problems started up which led to my resolving
the issues, but with one underlying question which I will get to shortly.
The goal is to setup two preconfigured RAID boxes which both come from
different servers and connect them through one Adaptec U320 controller
card on a dual Athlon MP Tyan motherboard. The two RAID boxes each
contain 14 U320 SCSI drives setup in a JBOD configuration with one box
being raid0 and the other raid5. Only one of the two boxes has exisitng
data on it and blowing it away was out of the question. The problem I
ran into was thought to be related strictly to the udev, hotplug, and
creation of the extra /dev/md1 needed for the second box. After a couple
of week of multiple emails with people and chasing this in circles I
decided to blow away the new RAID box setup of RAID5 and rebuild it
while the primary RAID box is still attached. First problem I
encountered was in rebuilding the RAID array with 'mdadm --create
......' which didn't work. In short, I had to blow away the drive
partitions, reboot, recreate the drive partitions then run the 'mdadm
--create ...' to make it rebuild the array. Then when I ran disk druid
to look at the drives I discovered what ended up being the root of all
my problems. Before me was the listing for two RAID boxes and oh by the
way both were labeled as /dev/md0. Now this is the whole source of the
problems which I had already come upon through different means, but disk
druid just proved my theory out.
So I rebuilt the array with the 'mdadm --create ...' command with the
addiiton of specifying the /dev/md1 connection. This also required the
manual creation of the /dev/md1 device file so the creation of the RAID
device could take place. After creation and a reboot the udev actually
discovered the second RAID with the superblock label for /dev/md1 and
did it's thing to make everything work now. This is great!!
Now the question: Is there anything in mdadm allowing one to take a
previously setup RAID box from another server and attach it to a second
SCSI port and modify only the superblocks to change out the /dev/md0 to
/dev/md1 or md2 or ....... so on?
This is very critical for managing the RAID boxes since if you already
have one /dev/md0 connection you can not easily have a second device
attached then connected to without errors or failure to setup the RAID
box if it too is /dev/md0.
My solution to this at this point in time is to make these two RAID
boxes be md4 and md5 while some of the other boxes become md0, md1, md2,
md3, and so on. Of course I will need to blow away all the data and then
rebuild the arrays from tapes.
Thanks for your time,
Bill Cronk
next reply other threads:[~2004-11-01 2:32 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-01 2:32 Bill Cronk [this message]
2004-11-01 3:06 ` Question regarding mdadm and RAID boxes Neil Brown
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=4185A048.1070308@cox.net \
--to=ngc4013@cox.net \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@cse.unsw.edu.au \
/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).