From: "David M. Strang" <dstrang@shellpower.net>
To: Forrest Taylor <ftaylor@redhat.com>
Cc: Michael Tokarev <mjt@tls.msk.ru>,
Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: raid5: Disk failure on sdm, disabling device
Date: Thu, 1 Sep 2005 03:38:01 -0400 [thread overview]
Message-ID: <00e001c5aec8$151f1d20$c100a8c0@NCNF5131FTH> (raw)
In-Reply-To: 1125526791.3194.32.camel@x1-6-00-0d-60-fd-e8-4c
Forrest Taylor wrote:
> > Michael Tokarev wrote:
> > > David M. Strang wrote:
> > > []
> > >
> > > > Is there something a little deeper to this error message?
> > > >
> > > > Aug 31 04:48:15 abyss kernel: scsi2 (12:0): rejecting I/O to offline
> > > > device
> > > > Aug 31 04:48:15 abyss kernel: raid5: Disk failure on sdm, disabling
> > > > device.
> > >
> > > If you reread my message, I hope you will find a bit of clue:
> > >
> > > echo y > /sys/block/sdm/device/delete
> > > (or something like that anyway.)
> > >
> > > That's needed for exactly this purpose: to remove a device which is
> > > marked 'offline' in the kernel somewhere - to be able to re-add it
> > > later - either with this script or just doing that magic
> > > add-single-device
> > > command manually.
> >
> > I should have listened sooner; I wasn't able to follow the paths in the
> > re-add command, so I didn't do the delete.
> >
> > I did the delete (the above syntax is correct) -- ran the rescan script,
> > it
> > added it back - and the device is accessable again.
> >
> > Thank you Michael & Forrest.
>
> I just noticed that in /sys/block/sda/device/, along with the delete
> file, there is a rescan file. I think that this is what I was thinking
> of with the 2.6 kernel.
Well, my worst fear was realized. My raid array barfed during rebuild. It
errorenously kicked a few devices from the array. I/O was not rejected to
any of the drives as was before; so I stopped the array. (mdadm --stop
/dev/md0) -- and re-assembled it;
mdadm -A /dev/md0 /dev/sda /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf
/dev/sdg /dev/sdh /dev/sdi /dev/sdj /dev/sdk /dev/sdl /dev/sdm /dev/sdn
/dev/sdo /dev/sdp /dev/sdq /dev/sdr /dev/sds /dev/sdt /dev/sdu /dev/sdv
/dev/sdw /dev/sdx /dev/sdy /dev/sdz /dev/sdaa /dev/sdab -f
Just as before;
mdadm: forcing event count in /dev/sda(0) from 337384 upto 2645518
mdadm: forcing event count in /dev/sdb(1) from 337384 upto 2645518
mdadm: forcing event count in /dev/sdc(2) from 337384 upto 2645518
mdadm: forcing event count in /dev/sdd(3) from 337384 upto 2645518
mdadm: forcing event count in /dev/sde(4) from 337384 upto 2645518
mdadm: forcing event count in /dev/sdf(5) from 337384 upto 2645518
mdadm: forcing event count in /dev/sdg(6) from 337384 upto 2645518
mdadm: forcing event count in /dev/sdh(7) from 337384 upto 2645518
mdadm: forcing event count in /dev/sdi(8) from 337384 upto 2645518
mdadm: forcing event count in /dev/sdj(9) from 337384 upto 2645518
mdadm: forcing event count in /dev/sdk(10) from 337384 upto 2645518
mdadm: forcing event count in /dev/sdl(11) from 337384 upto 2645518
mdadm: forcing event count in /dev/sdn(13) from 337384 upto 2645518
mdadm: forcing event count in /dev/sdo(14) from 337384 upto 2645518
mdadm: forcing event count in /dev/sdp(15) from 337384 upto 2645518
mdadm: forcing event count in /dev/sdq(16) from 337384 upto 2645518
mdadm: forcing event count in /dev/sdr(17) from 337384 upto 2645518
mdadm: forcing event count in /dev/sds(18) from 337384 upto 2645518
mdadm: forcing event count in /dev/sdt(19) from 337384 upto 2645518
mdadm: forcing event count in /dev/sdu(20) from 337384 upto 2645518
mdadm: forcing event count in /dev/sdv(21) from 337384 upto 2645518
mdadm: forcing event count in /dev/sdw(22) from 337384 upto 2645518
mdadm: forcing event count in /dev/sdx(23) from 337384 upto 2645518
mdadm: forcing event count in /dev/sdy(24) from 337384 upto 2645518
mdadm: forcing event count in /dev/sdz(25) from 337384 upto 2645518
mdadm: forcing event count in /dev/sdab(27) from 337384 upto 2645518
mdadm: /dev/md0 assembled from 26 drives - not enough to start the array.
The 2 drives, one of which was sync'd -- and one that was rebuilding; won't
join the array.
prev parent reply other threads:[~2005-09-01 7:38 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-31 19:26 raid5: Disk failure on sdm, disabling device David M. Strang
2005-08-31 19:28 ` Forrest Taylor
2005-08-31 19:38 ` David M. Strang
2005-08-31 19:29 ` Michael Tokarev
2005-08-31 19:41 ` David M. Strang
2005-08-31 20:07 ` Michael Tokarev
2005-08-31 20:28 ` David M. Strang
2005-08-31 20:35 ` Michael Tokarev
2005-08-31 20:39 ` Forrest Taylor
2005-08-31 20:45 ` David M. Strang
2005-08-31 20:53 ` David M. Strang
2005-08-31 20:59 ` Forrest Taylor
2005-08-31 20:53 ` Forrest Taylor
2005-08-31 21:01 ` David M. Strang
2005-08-31 21:02 ` Forrest Taylor
2005-08-31 21:05 ` David M. Strang
2005-08-31 21:29 ` Michael Tokarev
2005-08-31 21:34 ` David M. Strang
2005-08-31 22:19 ` Forrest Taylor
2005-09-01 7:38 ` David M. Strang [this message]
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='00e001c5aec8$151f1d20$c100a8c0@NCNF5131FTH' \
--to=dstrang@shellpower.net \
--cc=ftaylor@redhat.com \
--cc=linux-raid@vger.kernel.org \
--cc=mjt@tls.msk.ru \
/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