Date: Sun, 5 Oct 2003 14:48:56 +0930 From: Greg 'groggy' Lehey <grog@FreeBSD.org> To: aarong <aarong@megapathdsl.net> Cc: freebsd-questions@freebsd.org Subject: Re: Issues mirroring drives with Vinum in FreeBSD 4.8-RELEASE Message-ID: <20031005051856.GU45668@wantadilla.lemis.com> In-Reply-To: <41617EBD-F691-11D7-A2AE-000393A364C4@megapathdsl.net> References: <20031004083007.GF45668@wantadilla.lemis.com> <41617EBD-F691-11D7-A2AE-000393A364C4@megapathdsl.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--5baGGYxPGMjgwtsu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Saturday, 4 October 2003 at 10:36:15 -0700, aarong wrote: > On Saturday, October 4, 2003, at 01:30 AM, Greg 'groggy' Lehey wrote: >> I'd like to see the complaints. This is why I ask for the information >> in the man page or at http://www.vinumvm.org/vinum/how-to-debug.html. > > This is when booting regularly: > > ...dmesg... > vinum: reading configuration from /dev/da0s1h > vinum: reading configuration from /dev/da1s1h > vinum: using volume root for root device > Mounting root from ufs:/dev/vinum/root > swapon: adding /dev/vinum/swap as swap device > fstab: /etc/fstab:9: Inappropriate file type or format > Automatic boot in progress... > /dev/vinum/root: FILESYSTEM CLEAN; SKIPPING CHECKS > /dev/vinum/root: clean, 45939 free (633 frags, 5595 blocks, 1.0% > fragmentation) > fstab: /etc/fstab:9: Inappropriate file type or format > fstab: /etc/fstab:9: Inappropriate file type or format It's probably worth fixing this. > /dev/vinum/var: UNALLOCATED I=44035 OWNER=root MODE=0 > /dev/vinum/var: SIZE=0 MTIME=Oct 3 22:54 2003 > /dev/vinum/var: NAME=/run/dmesg.boot > > /dev/vinum/var: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY. > > Then I'm dropped into single user mode. Line 9 of /etc/fstab is proc, I > have no idea why its complaining since its valid, and I never changed > it. > > # fsck -n /dev/vinum/var > ... > ** Phase 5 - Check Cyl groups > FREE BLK COUNT(S) WRONG IN SUPERBLK > SALVAGE? no This can be normal. > SUMMARY INFORMATION BAD > SALVAGE? no So can this. > ALLOCATED FRAG 1277319 MARKED FREE > BLK(S) MISSING IN BIT MAPS > SALVAGE? no > > ALLOCATED FRAG 1368488 MARKED FREE > ...same message until 1368493... But these suggest something worse. The problem here is that it found the superblock, so it's likely that your geometry is correct: you wouldn't have got this far if you hadn't. > fsck'ing the rest of the volumes produces more of the same; one notable > difference is root has a reference count error in addition to missing > bit maps, bad summary information, and incorrect number of block counts > in the superblock. The usr volume seems to be fine according to fsck, > however. vinum list correctly notes both drives are up, four volumes > have two plexes, the 8 plexes are up and sized, and the subdisks are > up. fsck -n /dev/vinum/var before mirroring produced no complaints, > otherwise I'd conclude that I just mirrored a corrupt plex but that > doesn't seem to be the case. It looks something like that. In single user mode, do an fsck on each of the component plexes. My guess is that (at least) one plex of each volume will be bad. 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 See complete headers for address and phone numbers. --5baGGYxPGMjgwtsu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQE/f6nAIubykFB6QiMRAp+sAJ4zRiB2DFnCVCHMf9/BiJIPY+Gw/wCfYgUm 5OyVFIKtUnAQ9mO1lJTYdhA= =YgE1 -----END PGP SIGNATURE----- --5baGGYxPGMjgwtsu--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031005051856.GU45668>