* No resync
@ 2010-01-12 4:44 Richard Scobie
2010-01-12 4:52 ` Leslie Rhorer
0 siblings, 1 reply; 6+ messages in thread
From: Richard Scobie @ 2010-01-12 4:44 UTC (permalink / raw)
To: linux-raid
Is there a way to force assemble a stopped array that has too many
failed devices, while disabling the resync that would normally occur?
Regards,
Richard
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: No resync
2010-01-12 4:44 No resync Richard Scobie
@ 2010-01-12 4:52 ` Leslie Rhorer
2010-01-12 4:58 ` Richard Scobie
0 siblings, 1 reply; 6+ messages in thread
From: Leslie Rhorer @ 2010-01-12 4:52 UTC (permalink / raw)
To: 'Richard Scobie', linux-raid
> -----Original Message-----
> From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
> owner@vger.kernel.org] On Behalf Of Richard Scobie
> Sent: Monday, January 11, 2010 10:45 PM
> To: linux-raid@vger.kernel.org
> Subject: No resync
>
> Is there a way to force assemble a stopped array that has too many
> failed devices, while disabling the resync that would normally occur?
Well, of course if the array has too few members to start (even
after the --force), then it won't start and thus won't recync, but assuming
one has enough targets to assemble and run the array, I believe
--asume-clean will do what you want. It's in the man page.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: No resync
2010-01-12 4:52 ` Leslie Rhorer
@ 2010-01-12 4:58 ` Richard Scobie
2010-01-12 8:37 ` Robin Hill
0 siblings, 1 reply; 6+ messages in thread
From: Richard Scobie @ 2010-01-12 4:58 UTC (permalink / raw)
To: linux-raid
Leslie Rhorer wrote:
>> Is there a way to force assemble a stopped array that has too many
>> failed devices, while disabling the resync that would normally occur?
>
> Well, of course if the array has too few members to start (even
> after the --force), then it won't start and thus won't recync, but assuming
> one has enough targets to assemble and run the array, I believe
> --asume-clean will do what you want. It's in the man page.
>
By using force as part of an assemble, all failed devices set to healty
again and a resync is immediately started.
According to the man page --asume-clean is not an available option for
assemble.
I have tried --read-only but that is not an otion either.
I need to reassemble without resyncing so I can fsck first.
Regards,
Richard
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: No resync
2010-01-12 4:58 ` Richard Scobie
@ 2010-01-12 8:37 ` Robin Hill
2010-01-12 18:27 ` Richard Scobie
0 siblings, 1 reply; 6+ messages in thread
From: Robin Hill @ 2010-01-12 8:37 UTC (permalink / raw)
To: linux-raid
[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]
On Tue Jan 12, 2010 at 05:58:10PM +1300, Richard Scobie wrote:
> Leslie Rhorer wrote:
>
> >> Is there a way to force assemble a stopped array that has too many
> >> failed devices, while disabling the resync that would normally occur?
> >
> > Well, of course if the array has too few members to start (even
> > after the --force), then it won't start and thus won't recync, but assuming
> > one has enough targets to assemble and run the array, I believe
> > --asume-clean will do what you want. It's in the man page.
> >
>
> By using force as part of an assemble, all failed devices set to healty
> again and a resync is immediately started.
>
> According to the man page --asume-clean is not an available option for
> assemble.
>
> I have tried --read-only but that is not an otion either.
>
> I need to reassemble without resyncing so I can fsck first.
>
You probably need to start it with missing members then, so it's able to
run but not to resync.
Cheers,
Robin
--
___
( ' } | Robin Hill <robin@robinhill.me.uk> |
/ / ) | Little Jim says .... |
// !! | "He fallen in de water !!" |
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: No resync
2010-01-12 8:37 ` Robin Hill
@ 2010-01-12 18:27 ` Richard Scobie
2010-01-18 3:48 ` Neil Brown
0 siblings, 1 reply; 6+ messages in thread
From: Richard Scobie @ 2010-01-12 18:27 UTC (permalink / raw)
To: linux-raid
Robin Hill wrote:
> You probably need to start it with missing members then, so it's able to
> run but not to resync.
This is not an option in assemble mode either. It looks as though the
array has to be recreated. I'm not sure why any of these options are not
provided for assemble.
Anyway, in the end I did an "assemble --force" after stopping what was
left (5 drives dropped from a 16 drive RAID6), and it strated but did
not initiate a resync.
Perhaps the behaviour here has changed, because I'm sure when I've done
this in the past, it resyncs straight away.
There were some somewhat strange errors in the log:
Jan 12 17:09:09 sam kernel: end_request: I/O error, dev sdf, sector
1953182527
Jan 12 17:09:09 sam kernel: md: super_written gets error=-5, uptodate=0
Jan 12 17:09:09 sam kernel: raid5: Disk failure on sdf1, disabling device.
Jan 12 17:09:09 sam kernel: raid5: Operation continuing on 15 devices.
Jan 12 17:09:09 sam kernel: end_request: I/O error, dev sdh, sector
1953182527
Jan 12 17:09:09 sam kernel: md: super_written gets error=-5, uptodate=0
Jan 12 17:09:09 sam kernel: raid5: Disk failure on sdh1, disabling device.
Jan 12 17:09:09 sam kernel: raid5: Operation continuing on 14 devices.
Jan 12 17:09:09 sam kernel: end_request: I/O error, dev sdg, sector
1953182527
Jan 12 17:09:09 sam kernel: md: super_written gets error=-5, uptodate=0
Jan 12 17:09:09 sam kernel: raid5: Disk failure on sdg1, disabling device.
Jan 12 17:09:09 sam kernel: raid5: Operation continuing on 13 devices.
Jan 12 17:09:09 sam kernel: end_request: I/O error, dev sdp, sector
1953182527
Jan 12 17:09:09 sam kernel: md: super_written gets error=-5, uptodate=0
Jan 12 17:09:09 sam kernel: raid5: Disk failure on sdp1, disabling device.
Jan 12 17:09:09 sam kernel: raid5: Operation continuing on 12 devices.
Jan 12 17:09:09 sam kernel: end_request: I/O error, dev sdr, sector
1953182527
Jan 12 17:09:09 sam kernel: md: super_written gets error=-5, uptodate=0
Jan 12 17:09:09 sam kernel: raid5: Disk failure on sdr1, disabling device.
Jan 12 17:09:09 sam kernel: raid5: Operation continuing on 11 devices.
The cause is a controller problem, but after the first 2 drives were
disabled, I don't know why there were "raid5: Operation continuing
on..." messages as another 3 drives were offlined. A RAID6 array should
stop when a third device fails.
Regards,
Richard
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: No resync
2010-01-12 18:27 ` Richard Scobie
@ 2010-01-18 3:48 ` Neil Brown
0 siblings, 0 replies; 6+ messages in thread
From: Neil Brown @ 2010-01-18 3:48 UTC (permalink / raw)
To: Richard Scobie; +Cc: linux-raid
On Wed, 13 Jan 2010 07:27:20 +1300
Richard Scobie <richard@sauce.co.nz> wrote:
> Robin Hill wrote:
>
> > You probably need to start it with missing members then, so it's able to
> > run but not to resync.
>
> This is not an option in assemble mode either. It looks as though the
> array has to be recreated. I'm not sure why any of these options are not
> provided for assemble.
>
> Anyway, in the end I did an "assemble --force" after stopping what was
> left (5 drives dropped from a 16 drive RAID6), and it strated but did
> not initiate a resync.
This is what I would expect. When mdadm need to "fix" the array to get it to
assemble, it does the minimum work necessary to get the data available. That
means that it normally won't add any 'redundant' data so no resync will
happen. (RAID10 is a bit of an exception for complex reasons that I don't
want to go in to at the moment).
>
> Perhaps the behaviour here has changed, because I'm sure when I've done
> this in the past, it resyncs straight away.
I would be surprised... (but that does happen).
>
> There were some somewhat strange errors in the log:
>
> Jan 12 17:09:09 sam kernel: end_request: I/O error, dev sdf, sector
> 1953182527
> Jan 12 17:09:09 sam kernel: md: super_written gets error=-5, uptodate=0
> Jan 12 17:09:09 sam kernel: raid5: Disk failure on sdf1, disabling device.
> Jan 12 17:09:09 sam kernel: raid5: Operation continuing on 15 devices.
> Jan 12 17:09:09 sam kernel: end_request: I/O error, dev sdh, sector
> 1953182527
> Jan 12 17:09:09 sam kernel: md: super_written gets error=-5, uptodate=0
> Jan 12 17:09:09 sam kernel: raid5: Disk failure on sdh1, disabling device.
> Jan 12 17:09:09 sam kernel: raid5: Operation continuing on 14 devices.
> Jan 12 17:09:09 sam kernel: end_request: I/O error, dev sdg, sector
> 1953182527
> Jan 12 17:09:09 sam kernel: md: super_written gets error=-5, uptodate=0
> Jan 12 17:09:09 sam kernel: raid5: Disk failure on sdg1, disabling device.
> Jan 12 17:09:09 sam kernel: raid5: Operation continuing on 13 devices.
> Jan 12 17:09:09 sam kernel: end_request: I/O error, dev sdp, sector
> 1953182527
> Jan 12 17:09:09 sam kernel: md: super_written gets error=-5, uptodate=0
> Jan 12 17:09:09 sam kernel: raid5: Disk failure on sdp1, disabling device.
> Jan 12 17:09:09 sam kernel: raid5: Operation continuing on 12 devices.
> Jan 12 17:09:09 sam kernel: end_request: I/O error, dev sdr, sector
> 1953182527
> Jan 12 17:09:09 sam kernel: md: super_written gets error=-5, uptodate=0
> Jan 12 17:09:09 sam kernel: raid5: Disk failure on sdr1, disabling device.
> Jan 12 17:09:09 sam kernel: raid5: Operation continuing on 11 devices.
>
> The cause is a controller problem, but after the first 2 drives were
> disabled, I don't know why there were "raid5: Operation continuing
> on..." messages as another 3 drives were offlined. A RAID6 array should
> stop when a third device fails.
Yes it should .... I really should tidy that code up.
NeilBrown
>
> Regards,
>
> Richard
> --
> 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 [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-01-18 3:48 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-01-12 4:44 No resync Richard Scobie
2010-01-12 4:52 ` Leslie Rhorer
2010-01-12 4:58 ` Richard Scobie
2010-01-12 8:37 ` Robin Hill
2010-01-12 18:27 ` Richard Scobie
2010-01-18 3:48 ` Neil Brown
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).