linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Alger <linux-raid@mm.quex.org>
To: linux-raid@vger.kernel.org
Subject: Updating superblock to reflect new disc locations
Date: Wed, 11 Jan 2006 13:20:58 +0800	[thread overview]
Message-ID: <43C495BA.9070502@mm.quex.org> (raw)

I'm running Debian sarge on a system with two IDE drives. I used the 
installer to create a mirrored filesystem on the first partition of both 
discs and it's mounted as the root; everything was working fine.

Unfortunately, I noticed the two devices were on the same IDE channel 
(i.e. /dev/hda1 and /dev/hdb1), so I moved them on to different channels 
(/dev/hda1 and /dev/hdc1). Now, the array only finds the one device when 
it starts up (/dev/hda1). In case it's relevant, because of the cable 
lengths the drives moved as follows:

dev/hda -> dev/hdc
dev/hdb -> dev/hda

I believe all I really need to do is update the superblock on /dev/hda1 
so the md driver knows to look at /dev/hdc1 rather than /dev/hdb1. 
Unfortunately, I can't work out how to do this. The only references I've 
seen to rewriting the superblock is with mdadm --assemble, but I can't 
use that because it's already running.

I've tried removing both drives from the array (not at the same time, of 
course), then re-adding them and waiting for it to finish syncing, but 
that doesn't help. After a reboot, I still get the same problem. In 
fact, now it looks like it's not even trying /dev/hdb1; it looks like it 
recorded the fact I had removed the drive, but not the fact I'd added it 
again.

After using mdadm --manage /dev/md0 --add /dev/hdc1 and waiting for the 
array to resync, the superblock info on both discs match.

Below is the current situation in terms of mdadm output, after re-adding 
/dev/hdc1 to /dev/md0 and waiting for it to resync. (md1 is on hda1 and 
hdc1, and has the same problem.)


# cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 hda3[1]
      9767424 blocks [2/1] [_U]

md0 : active raid1 hdc1[0] hda1[1]
      2441728 blocks [2/2] [UU]

unused devices: <none>


The superblocks look correct to me, as the following shows:

# mdadm --misc --examine /dev/hda1
/dev/hda1:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : d2b494fc:a181e190:a09f1dfb:b226ea79
  Creation Time : Tue Jan 10 15:53:02 2006
     Raid Level : raid1
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0

    Update Time : Wed Jan 11 13:10:10 2006
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0
       Checksum : f7d5252c - correct
         Events : 0.3266

      Number   Major   Minor   RaidDevice State
this     1       3        1        1      active sync   /dev/hda1

   0     0      22        1        0      active sync   /dev/hdc1
   1     1       3        1        1      active sync   /dev/hda1

# mdadm --misc --examine /dev/hdc1
/dev/hdc1:
(I removed the status information here to make it more readable; it is 
identical for both devices, so it looks like they are properly 
synchronized.)

      Number   Major   Minor   RaidDevice State
this     0      22        1        0      active sync   /dev/hdc1

   0     0      22        1        0      active sync   /dev/hdc1
   1     1       3        1        1      active sync   /dev/hda1



After a reboot:

# cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 hda3[1]
      9767424 blocks [2/1] [_U]

md0 : active raid1 hda1[1]
      2441728 blocks [2/1] [_U]

unused devices: <none>

# mdadm --misc --examine /dev/hda1
/dev/hda1:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : d2b494fc:a181e190:a09f1dfb:b226ea79
  Creation Time : Tue Jan 10 15:53:02 2006
     Raid Level : raid1
   Raid Devices : 2
  Total Devices : 1
Preferred Minor : 0

    Update Time : Wed Jan 11 13:17:37 2006
          State : clean
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0
       Checksum : f7d5275f - correct
         Events : 0.3336


      Number   Major   Minor   RaidDevice State
this     1       3        1        1      active sync   /dev/hda1

   0     0       0        0        0      removed
   1     1       3        1        1      active sync   /dev/hda1

# mdadm --misc --examine /dev/hdc1
/dev/hdc1:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : d2b494fc:a181e190:a09f1dfb:b226ea79
  Creation Time : Tue Jan 10 15:53:02 2006
     Raid Level : raid1
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0

    Update Time : Wed Jan 11 13:12:00 2006
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0
       Checksum : f7d525d7 - correct
         Events : 0.3288


      Number   Major   Minor   RaidDevice State
this     0      22        1        0      active sync   /dev/hdc1

   0     0      22        1        0      active sync   /dev/hdc1
   1     1       3        1        1      active sync   /dev/hda1


Relevant parts of the boot process:

Kernel command line: root=/dev/md0 ro
hda: ST380011A, ATA DISK drive
Using anticipatory io scheduler
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: max request size: 128KiB
hda: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=65535/16/63, 
UDMA(100)
 /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 p4 < p5 p6 >
hdc: ST380011A, ATA DISK drive
ide1 at 0x170-0x177,0x376 on irq 15
hdc: max request size: 128KiB
hdc: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=65535/16/63, 
UDMA(100)
 /dev/ide/host0/bus1/target0/lun0: p1 p2 p3 p4 < p5 p6 >
md: md0 stopped.
md: bind<hda1>
raid1: raid set md0 active with 1 out of 2 mirrors


Any suggestions would be greatly appreciated. The system's new and not 
yet in production, so I can reinstall it if I have to, but I'd prefer to 
be able to fix something as simple as this.

             reply	other threads:[~2006-01-11  5:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-11  5:20 Michael Alger [this message]
2006-01-12  3:01 ` Updating superblock to reflect new disc locations Neil Brown
2006-01-12  3:49   ` dean gaudet
2006-01-12  4:31     ` Michael Alger

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=43C495BA.9070502@mm.quex.org \
    --to=linux-raid@mm.quex.org \
    --cc=linux-raid@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;
as well as URLs for NNTP newsgroup(s).