So I guess what I am trying to figure out if sdb is bad or not.
I will run the scsi utitility on it after hours... but does anyone know
how 'time inconsistencies in the superblock' generally arise?
--A
------
ai
http://sefiroth.org
On Wed, 28 Jun 2000, m. allan noah wrote:
> well, if you have identified the drive, you should replace it with one that
> works (or just assume the one you have is ok, which might be a bad idea)
>
> then partition the new disk so that the size of the partitions matches the
> partitions on the dead disk (or is each partition is slightly larger)
>
> then use the command 'raidhotadd' to insert the partitions on this disk into
> the running arrays, like so:
>
> raidhotadd /dev/md0 /dev/sdb1
>
> (if sdb1 should be part of md0)
>
> repeat this command for each md* and sdb* combo you have.
>
> now watch /proc/mdstat it should tell you that the array is syncing.
>
> wait till all the syncing is done before you reboot.
>
> you probably should also make sure your /etc/raidtab reflects the changes you
> made for the next time this happens.
>
> allan
>
> Anton <[EMAIL PROTECTED]> said:
>
> > Thanks a lot, mr. m!
> > still no one seems to know what to do with a bad superblock on a drive...
> >
> > ------
> > ai
> > http://sefiroth.org
> >
> > On Wed, 28 Jun 2000, m. allan noah wrote:
> >
> > > anton, run this command as root:
> > >
> > > dd if=/dev/sdb of=/dev/null count=100 bs=1k
> > >
> > > this will dump some data out of your scsi disk, and into /dev/null check
> the
> > > light :)
> > >
> > > if you miss it, increase the count.
> > >
> > > allan
> > >
> > > Anton <[EMAIL PROTECTED]> said:
> > >
> > > > So I have a total of 7 disks in the system, 6 of which are in the RAID
> and
> > > > I need to know that if I want to swap sdb1, which physical disk do I
> > > > replace... I know that there is a utility for windows which makes the
> > > > drive's LED flash.
> > > >
> > > > I am still looking for a resolution to the
> > > >
> > > > md: superblock update time inconsistency -- using the most recent one
> > > > freshest: sdg1
> > > > md: kicking non-fresh sdb1 from array!
> > > > unbind<sdb1,5>
> > > > export_rdev(sdb1)
> > > >
> > > > problem. Thanks.
> > > > ------
> > > > ai
> > > > http://sefiroth.org
> > > >
> > > > On Wed, 28 Jun 2000, Gregory Leblanc wrote:
> > > >
> > > > > > -----Original Message-----
> > > > > > From: [EMAIL PROTECTED]
> > > > > > [mailto:[EMAIL PROTECTED]]
> > > > > > Sent: Tuesday, June 27, 2000 5:00 PM
> > > > > > To: [EMAIL PROTECTED]
> > > > > > Subject: Re: problem with superblock
> > > > > >
> > > > > > ## Betreff : problem with superblock
> > > > > > ## Ersteller: [EMAIL PROTECTED] (Anton)
> > > > > >
> > > > > > a> And is how do you map
> > > > > > a> names like sdb1 to the physical disk?
> > > > > > It is the first disk on the second SCSI-Controller.
> > > > >
> > > > > Uhm, no, it's not. The stock Linux kernel maps SCSI drives in the
> order
> > > > > that it finds them. The first SCSI disk is /dev/sda, the second is
> > > > > /dev/sdb, the third, /dev/sdc, and so on. /dev/sdb1 is the first
> > > partition
> > > > > on the second SCSI drive. If you add another SCSI disk that the
> kernel
> > > > > finds earlier, then that disk will no longer be /dev/sdb, but some
> other
> > > > > disk. Persistent superblocks make sure that your RAID arrays can
> start up
> > > > > even when you change the number of SCSI disks in your system.
> > > > > Grego
> > > > >
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > >
> > >
> > >
> >
> >
>
>
>
>
