Re: vinum revive does not rebuild parity (was vinum rebuildparity, when?)
On Thursday, 2 September 2004 at 12:17:01 +0200, Stijn Hoop wrote: Hi, back with another episode in this continuing saga: On Sun, Aug 29, 2004 at 04:26:57PM +0200, Stijn Hoop wrote: Witness this (after yet another fake disk crash): vinum - ls -v local.p0.s0 Subdisk local.p0.s0: Size: 31457129472 bytes (2 MB) State: reviving Plex local.p0 at offset 0 (0 B) Reviver PID:46863 Revive pointer: 22 GB (77%) Revive blocksize: 64 kB Revive interval: 0 seconds Drive ren (/dev/ad6s1e) at offset 135680 (132 kB) vinum - vinum[46863]: local.p0.s0 is up vinum - checkparity local.p0.s0 local.p0.s0 is not a plex vinum - checkparity local.p0 Parity incorrect at offset 0x2020 vinum - rebuildparity -V local.p0 Parity incorrect at offset 0x2020 Rebuilding at 2703 kB (0%)Parity incorrect at offset 0x2a6664 Rebuilding at 139 MB (0%) which indicates that the parity surely is not correctly recalculated during the revive. If that were the case, the parity would be incorrect at offset 0. Yes, it is recalculated. Greg, can you tell me if this is correct behaviour? Sorry for the slow response. I was at a conference last week. No, it's not correct. While not having heard back yet, I had to rebuild another subdisk, but I decided to do it off-line this time. Turns out the parity was rebuilt ok. Yes, this is what I recommended. Might there be a bug in the online rebuild code? Looks like it. The current version of Vinum is on its last legs. Lukas Ertl is rewriting it, so don't expect much change in this version. For the time being, just accept that you should umount before rebuilding a plex. Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply or reply to the original recipients. For more information, see http://www.lemis.com/questions.html Note: I discard all HTML mail unseen. Finger [EMAIL PROTECTED] for PGP public key. See complete headers for address and phone numbers. pgpQicdKRk1u7.pgp Description: PGP signature
Re: vinum revive does not rebuild parity (was vinum rebuildparity, when?)
On Wed, Sep 08, 2004 at 11:28:46AM +0930, Greg 'groggy' Lehey wrote: [...] the parity surely is not correctly recalculated during the revive. If that were the case, the parity would be incorrect at offset 0. Yes, it is recalculated. Of course -- I hadn't thought of that. Greg, can you tell me if this is correct behaviour? Sorry for the slow response. I was at a conference last week. No, it's not correct. No problem; this is still a volunteer project last time I checked. In a way I am glad to hear that it is not correct. While not having heard back yet, I had to rebuild another subdisk, but I decided to do it off-line this time. Turns out the parity was rebuilt ok. Yes, this is what I recommended. OK. Might there be a bug in the online rebuild code? Looks like it. The current version of Vinum is on its last legs. Lukas Ertl is rewriting it, so don't expect much change in this version. For the time being, just accept that you should umount before rebuilding a plex. I will; it's just that somehow I was led to believe that I didn't need to do that. This has caused me some pain in the past. May I suggest applying the attached patch to /usr/src/sbin/vinum/vinum.8? At least it would prevent someone else from making the same mistakes as me. Thanks for your response, --Stijn -- The problem is that there are several people in design positions now who couldn't design the Next Big Thing(TM) unless it involved them taking a photocopier and someone else's design of The Next Big Thing(TM). -- 'Alkaiser' in a post on Slashdot on game originality --- vinum.8.origWed Sep 8 06:47:46 2004 +++ vinum.8 Wed Sep 8 06:51:19 2004 @@ -441,6 +441,10 @@ .Ic checkparity prints a running progress report. .Pp +It is advisable to always check the parity of a RAID-4 or RAID-5 plex after +an unclean shutdown. Corrupt parity is as bad as degraded mode for such a +plex; if one of the subdisks of such a plex fails, data corruption will occur. +.Pp .It Xo .Ic concat .Op Fl f @@ -1046,6 +1050,11 @@ flag is specified, .Ic rebuildparity prints a running progress report. +.Pp +At present, a bug prevents rebuildparity from correctly completing its job +when the vinum volume is mounted and being accessed. You should only rebuild +the parity of plexes on unmounted volumes in order to guarantee correct parity +checks. .Pp .It Xo .Ic rename pgp2yuf5apg1p.pgp Description: PGP signature
Re: vinum revive does not rebuild parity (was vinum rebuildparity, when?)
Hi, back with another episode in this continuing saga: On Sun, Aug 29, 2004 at 04:26:57PM +0200, Stijn Hoop wrote: Witness this (after yet another fake disk crash): %%% vinum - ls -v local.p0.s0 Subdisk local.p0.s0: Size: 31457129472 bytes (2 MB) State: reviving Plex local.p0 at offset 0 (0 B) Reviver PID:46863 Revive pointer: 22 GB (77%) Revive blocksize: 64 kB Revive interval: 0 seconds Drive ren (/dev/ad6s1e) at offset 135680 (132 kB) vinum - vinum[46863]: local.p0.s0 is up vinum - checkparity local.p0.s0 local.p0.s0 is not a plex vinum - checkparity local.p0 Parity incorrect at offset 0x2020 vinum - rebuildparity -V local.p0 Parity incorrect at offset 0x2020 Rebuilding at 2703 kB (0%)Parity incorrect at offset 0x2a6664 Rebuilding at 139 MB (0%) %%% which indicates that the parity surely is not correctly recalculated during the revive. Greg, can you tell me if this is correct behaviour? While not having heard back yet, I had to rebuild another subdisk, but I decided to do it off-line this time. Turns out the parity was rebuilt ok. Might there be a bug in the online rebuild code? I'm running FreeBSD 4.10-RELEASE on this box... --Stijn -- The right half of the brain controls the left half of the body. This means that only left handed people are in their right mind. pgpFhStMNbgBJ.pgp Description: PGP signature
vinum revive does not rebuild parity (was vinum rebuildparity, when?)
On Fri, Aug 27, 2004 at 02:24:46PM +0200, Christian Laursen wrote: Stijn Hoop [EMAIL PROTECTED] writes: On Wed, Aug 25, 2004 at 12:08:53PM +0200, Christian Laursen wrote: When reviving a disk the data on that disk is calculated from the data and the parity on the other disks. Yes, but the parity should be recalculated at the same time, right? Yes. Witness this (after yet another fake disk crash): %%% vinum - ls -v local.p0.s0 Subdisk local.p0.s0: Size: 31457129472 bytes (2 MB) State: reviving Plex local.p0 at offset 0 (0 B) Reviver PID:46863 Revive pointer: 22 GB (77%) Revive blocksize: 64 kB Revive interval: 0 seconds Drive ren (/dev/ad6s1e) at offset 135680 (132 kB) vinum - vinum[46863]: local.p0.s0 is up vinum - checkparity local.p0.s0 local.p0.s0 is not a plex vinum - checkparity local.p0 Parity incorrect at offset 0x2020 vinum - rebuildparity -V local.p0 Parity incorrect at offset 0x2020 Rebuilding at 2703 kB (0%)Parity incorrect at offset 0x2a6664 Rebuilding at 139 MB (0%) %%% which indicates that the parity surely is not correctly recalculated during the revive. Greg, can you tell me if this is correct behaviour? --Stijn -- Q: Why is Batman better than Bill Gates? A: Batman was able to beat the Penguin. pgpL3Jm3Sa7SQ.pgp Description: PGP signature
