Re: Vinum Raid5 Init question
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 4.12 release. > > 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 :). Craig ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Vinum Raid5 Init question
On Tuesday, 18 January 2005 at 8:33:03 -0600, Craig Boston wrote: > On Tue, Jan 18, 2005 at 12:21:59PM +0100, David Elsing wrote: >> Quote from the manual of the 4th example of the chapter "HOW TO SET UP >> VINUM": >> "In addition, the volume specification includes the keyword >> setupstate, which ensures that all plexes are up after creation." Where does it tell you to do that? From the man page: setstate state [volume | plex | subdisk | drive] setstate sets the state of the specified objects to the specified state. This bypasses the usual consistency mechanism of vinum and should be used only for recovery purposes. It is possible to crash the system by incorrect use of this command. >> But a couple of weeks later I read the following in the manual: >> >> "Note that you must use the init command with RAID-5 plexes: otherwise >> extreme data corruption will result if one subdisk fails." > > Yes, this particular gotcha bit me a while back and I lost quite a bit > of data (my fault for not having good backups) due to it. IMO, I still > consider it a documentation bug though. That particular bit is buried > in a command reference section rather than being in bold in the "HOW TO" > guide. Yes, it could be clearer. Put in a PR. >> I read this to my horror after I filled the volume with data. You'll >> probably noticed I didn't init my volume. The disks are in good >> condition. The volume is almost filled to the maximum capacity. So a >> backup is a bit difficult due to the size of it. Are there any other >> options? If one disks fails, do I still get corrupted data? > > Yes, if one disk fails for any reason, every third sector will be > garbage and it's unlikely you'll be able to recover anything useful from > it. > > I would highly recommend backing up whatever is critically important to > you asap. If you like living dangerously and all the drives are in good > health, the parity data can be (theoretically) repaired with the "vinum > rebuildparity" command, but do so at your own risk... That did allow me > to recover a couple of my partitions that hadn't been trashed yet. This should work. Make sure the volume is not be mounted when you do so. > 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. > That's what happened to me: ATA timeout caused one of the drives to > temporarily detach, corrupt filesystems caused a panic. If this > happens, you're better off using setstate to force it to up, as > wrong as that would normally be. I can't recall seeing a problem report. Greg -- See complete headers for address and phone numbers. pgpwjAvca7PjY.pgp Description: PGP signature
Re: Vinum Raid5 Init question
On Tue, Jan 18, 2005 at 12:21:59PM +0100, David Elsing wrote: > Quote from the manual of the 4th example of the chapter "HOW TO SET UP VINUM": > "In addition, the volume specification includes the keyword > setupstate, which ensures that all plexes are up after creation." > > But a couple of weeks later I read the following in the manual: > > "Note that you must use the init command with RAID-5 plexes: otherwise > extreme data corruption will result if one subdisk fails." Yes, this particular gotcha bit me a while back and I lost quite a bit of data (my fault for not having good backups) due to it. IMO, I still consider it a documentation bug though. That particular bit is buried in a command reference section rather than being in bold in the "HOW TO" guide. > I read this to my horror after I filled the volume with data. You'll > probably noticed I didn't init my volume. The disks are in good > condition. The volume is almost filled to the maximum capacity. So a > backup is a bit difficult due to the size of it. Are there any other > options? If one disks fails, do I still get corrupted data? Yes, if one disk fails for any reason, every third sector will be garbage and it's unlikely you'll be able to recover anything useful from it. I would highly recommend backing up whatever is critically important to you asap. If you like living dangerously and all the drives are in good health, the parity data can be (theoretically) repaired with the "vinum rebuildparity" command, but do so at your own risk... That did allow me to recover a couple of my partitions that hadn't been trashed yet. 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. That's what happened to me: ATA timeout caused one of the drives to temporarily detach, corrupt filesystems caused a panic. If this happens, you're better off using setstate to force it to up, as wrong as that would normally be. I've also noticed that sometimes the parity gets out of sync on its own, but I don't know the cause. I used to have a cron job that ran vinum checkparity once a month in the background and occasionally it would find sectors that needed to be rebuilt. Unfortunately this doesn't seem to be implemented with gvinum (5.3) yet. > ...know if any manual maintainer is reading this, but is it possible > to add this warning to the RAID5 example at the end of vinum(8)? I'll second this idea, at least for 4.x. I'm not sure how gvinum handles things as I haven't built any RAID5 volumes from scratch using it. Craig ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
