From owner-freebsd-current Sun Dec 26 18: 1:36 1999 Delivered-To: freebsd-current@freebsd.org Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (Postfix) with ESMTP id 5546014C8E for ; Sun, 26 Dec 1999 18:01:31 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id MAA42498; Mon, 27 Dec 1999 12:31:24 +1030 (CST) Date: Mon, 27 Dec 1999 12:31:24 +1030 From: Greg Lehey To: Gary Palmer Cc: current@freebsd.org Subject: Re: ``how to'' for Vinum and mirroring after the volume was created? Message-ID: <19991227123124.U1316@freebie.lemis.com> References: <19991227120444.S1316@freebie.lemis.com> <41777.946259657@noop.colo.erols.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <41777.946259657@noop.colo.erols.net> WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sunday, 26 December 1999 at 20:54:17 -0500, Gary Palmer wrote: > Greg Lehey wrote in message ID > <19991227120444.S1316@freebie.lemis.com>: >> Did you forget the 'setupstate' keyword? > > How would that apply? The 2nd disk was not consistant as it was added > after the data was copied onto the first and the old disks removed. Ah. I misunderstood. Yes, in this case you have to revive. >> [reading from the plex being revived] >> How do you determine that? > > Looking at the stats vinum provided. Unfortunately they're gone from > my scrollback buffer, but the 2nd plex was being read from, which is > not something I'd expect from what should have been a straight copy > from the first to the second. Also, if I remember right, the read > data from the first plex was going up more slowly than the written > data to the 2nd plex, which indicates to me that it may indeed have > been round-robining the reads, even though the 2nd plex wasn't > consistant. It occurs to me that it is, in fact, correct to read from a volume being revived. The data is consistent up to the point where the revive has progressed, so the system can read from this area. Check the function checksdstate() in vinumstate.c: if (diskaddr > (sd->revived + sd->plexoffset + (sd->revive_blocksize >> DEV_BSHIFT))) /* we're beyond the end */ return REQUEST_DOWN; else if (diskend > (sd->revived + sd->plexoffset)) { /* we finish beyond the end */ if (writeop) { rq->flags |= XFR_REVIVECONFLICT; /* note a potential conflict */ rq->sdno = sd->sdno; /* and which sd last caused it */ } else return REQUEST_DOWN; } >>> The second question concerns the flag fields. Is there any way to >>> change flags on the fly? e.g. change the volume from being round >>> robin to prefer plex? > >> That's one thing I haven't done yet. It's trivial, but I haven't >> thought of a syntax for the command. Suggestions? > > I think (at least to my mind) the best way to abstract it would be as > readflags/setflags commands, and do it so that it would work for flags > on the volume, plex, subdisk or disk level. I don't know how many > flags you really want to expose to the end-user, but I can imagine as > the product develops, more flags will be added. e.g. veritas has > user-settable comments fields. > > e.g. > > vinum setflag vol01 readpol=prefer preferplex=plex01 > > (that is a tricky one, as you really are setting two flags I would > imagine, not just one) Hmm. This looks too VERITAS-like for my liking. In addition, this isn't a flag. Internally it's represented as a plex index, with -1 meaning "round robin". I've tried to keep away from this sort of stuff. I was thinking of something more like: vinum prefer volfoo plexbar or vinum prefer volfoo -1 The second example is supposed to set round robin. I don't like that syntax either. Maybe the second example should be just vinum prefer volfoo. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message