Vinum Raid5 Init question
craig at feniz.gank.org
Tue Jan 18 16:21:51 PST 2005
On Wed, Jan 19, 2005 at 09:55:25AM +1030, Greg 'groggy' Lehey wrote:
> Yes, it could be clearer. Put in a PR.
I'm more than willing to submit a patch if it will help, but will it do
any good this late in the release cycle? Especially if there will be no
> > Also, if a good disk gets marked as "down" somehow before you can
> > correct this, whatever you do, do NOT issue a "vinum start" command
> > on it. In the current state of the array, that would be destructive
> > and irreversible.
> No, that's the correct way to do it.
Normally it would be, yes. However in this case (at least it was for
me), all of the normal blocks are fine, but the parity blocks are random
garbage since init was never run. If a drive goes into the "down" state
for some reason but is physically fine, starting the subdisk will begin
"reconstructing" the data from the bogus parity, wiping out any hope of
recovering the good data.
If a drive does get detached somehow, it's likely that the system won't
stay up very long -- from its point of view at least one filesystem has
suddenly become very corrupt. The setstate is dangerous and will
probably result in a somewhat inconsistent filesystem, but it's still
preferable to a total loss...
> I can't recall seeing a problem report.
There wasn't one. I had encountered the problem on several machines in
a short timespan (fortunately only one had anything important) so I
asked you about in in private mail. I didn't think the problem was with
FreeBSD or vinum itself -- it was more of a "what am I doing wrong?"
question. After a couple rounds you determined that it was likely I
hadn't run vinum init, and sure enough that's what it was.
Sorry, I can't provide a time reference. At the time of the exchange
my mail archive was down (that's what was on the doomed filesystem :).
More information about the freebsd-stable