From owner-freebsd-questions@FreeBSD.ORG Mon Feb 16 23:23:14 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1014516A4CE for ; Mon, 16 Feb 2004 23:23:14 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F27743D1F for ; Mon, 16 Feb 2004 23:23:13 -0800 (PST) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (blackwater.lemis.com [192.109.197.80]) by ozlabs.org (Postfix) with ESMTP id A4ED12BD53 for ; Tue, 17 Feb 2004 18:23:09 +1100 (EST) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 3CAEC51200; Tue, 17 Feb 2004 17:53:06 +1030 (CST) Date: Tue, 17 Feb 2004 17:53:06 +1030 From: Greg 'groggy' Lehey To: Tony Frank Message-ID: <20040217072306.GH33797@wantadilla.lemis.com> References: <20040216110444.GA83416@marvin.home.local> <20040216232130.GR33797@wantadilla.lemis.com> <20040217003926.GA19004@marvin.home.local> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FBimzwWXDeO/tHP5" Content-Disposition: inline In-Reply-To: <20040217003926.GA19004@marvin.home.local> User-Agent: Mutt/1.4.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 cc: freebsd-questions@freebsd.org Subject: Re: vinum raid5 subdisks keep changing length? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2004 07:23:14 -0000 --FBimzwWXDeO/tHP5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tuesday, 17 February 2004 at 11:39:26 +1100, Tony Frank wrote: > On Tue, Feb 17, 2004 at 09:51:30AM +1030, Greg 'groggy' Lehey wrote: >> On Monday, 16 February 2004 at 22:04:44 +1100, Tony Frank wrote: >>> The original config looked as so: >>> >>> volume data >>> plex name data.p0 org raid5 984s vol data >>> sd name data.p0.s0 drive eightgig plex data.p0 len 8802864s driveoffset 6335201s plexoffset 0s >>> sd name data.p0.s1 drive vinumdrive0 plex data.p0 len 8802864s driveoffset 265s plexoffset 984s >>> sd name data.p0.s2 drive vinumdrive1 plex data.p0 len 8802864s driveoffset 265s plexoffset 1968s >>> sd name data.p0.s3 drive vinumdrive2 plex data.p0 len 8802864s driveoffset 265s plexoffset 2952s >>> sd name data.p0.s4 drive vinumdrive3 plex data.p0 len 8802864s driveoffset 265s plexoffset 3936s >>> >>> Now after each system reboot I see messages on system console from vinum. >>> (they are not logged in vinum_history or messages) >> >> These messages should appear in /var/log/messages. Have you changed >> your syslogd.conf? > > No, default 4.9 config file, the vinum messages do not show up in 'dmesg' either. > I have changed to include the 'all.log' and 'console.log' in the syslogd.conf so > I will see if that changes this behaviour. Strange. It works fine for me: Feb 17 17:28:23 monorchid /kernel: vinum: loaded Feb 17 17:28:28 monorchid /kernel: vinum: reading configuration from /dev/da1s4h Feb 17 17:28:28 monorchid /kernel: vinum: updating configuration from /dev/da2s4h Feb 17 17:28:28 monorchid /kernel: vinum: updating configuration from /dev/da3s4h Feb 17 17:28:28 monorchid /kernel: vinum: updating configuration from /dev/da4s4h >>> vinum: updating configuration from /dev/ad0s1h >>> #(repeated for all 6 drives) >>> vinum: removing 2560 blocks of partial stripe at the end of data.p0 >> >> Yes, this is a feature, not a bug. > > While I accept this for a striped plex made up with subdisk of unequal length, > I had already taken that into account, hence the original subdisk length: > 8946 * 984 = 8802864 OK. I didn't go through the calculations. > As I understand it, this should have resulted in a whole number of > stripes. I have 5 subdisks so I'm not sure if I should have > factored that into my calculations? No, that makes no difference. >>> A "vinum printconfig" now shows difference values for the subdisks. >>> This value has changed after each reboot. >>> Current relevant parts of 'printconfig' are: >>> volume data >>> plex name data.p0 org raid5 984s vol data >>> sd name data.p0.s0 drive eightgig plex data.p0 len 8799978s driveoffset 6335201s plexoffset 0s >>> sd name data.p0.s1 drive vinumdrive0 plex data.p0 len 8799486s driveoffset 265s plexoffset 984s >>> sd name data.p0.s2 drive vinumdrive1 plex data.p0 len 8799158s driveoffset 265s plexoffset 1968s >>> sd name data.p0.s3 drive vinumdrive2 plex data.p0 len 8798420s driveoffset 265s plexoffset 2952s >>> sd name data.p0.s4 drive vinumdrive3 plex data.p0 len 8797600s driveoffset 265s plexoffset 3936s OK, I tried almost exactly the same thing. My disks are fractionally smaller than yours, so I took a different integral number of stripes. I didn't get any messages, and the config now looks like: volume data plex name data.p0 org raid5 984s vol data sd name data.p0.s0 drive drive1 plex data.p0 len 8374824s driveoffset 265s plexoffset 0s sd name data.p0.s1 drive drive2 plex data.p0 len 8374824s driveoffset 265s plexoffset 984s sd name data.p0.s2 drive drive3 plex data.p0 len 8374824s driveoffset 265s plexoffset 1968s sd name data.p0.s3 drive drive4 plex data.p0 len 8374824s driveoffset 265s plexoffset 2952s sd name data.p0.s4 drive drive5 plex data.p0 len 8374824s driveoffset 265s plexoffset 3936s I've stopped and started vinum a couple of times, and all works well. I then removed the objects and tried again with subdisks 4 sectors longer. Vinum gives the message: vinum: removing 16 blocks of partial stripe at the end of data.p0 printconfig is then identical with the previous version. >> This is a bug, not a feature. I'll try to take a look at it today. > > Please advise if I can help - I have plenty of free time this week > and am willing to get my hands dirty. Hmm. Unfortunately, I don't have much time for the rest of the week. Does this mean you're not coming to the AUUG security symposium in Canberra? > Another item (which I think I read about somewhere but can no longer > find the reference) is that after a reboot the vinum drives all > reference da0h ad2h etc rather than the original value of ad2s1h > da0s1h. That in itself is not a worry. It's the way Vinum works (the two are equivalent). > Also after the reboot, each drive is shown as 100% free which is a > concern. That is indeed a concern. There's obviously something going on here which isn't immediately obvious. Take a look at http://www.vinumvm.org/vinum/how-to-debug.html and send me the information I ask for there, and maybe we can track it down. 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. --FBimzwWXDeO/tHP5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQFAMcFaIubykFB6QiMRApSdAKCWUa9HdcS7MORTYhx321NoBBEjtACfW0Mt meNMLS6OhxbndA25HIqFmkc= =lKQj -----END PGP SIGNATURE----- --FBimzwWXDeO/tHP5--