On Sunday, 26 December 1999 at 20:54:17 -0500, Gary Palmer wrote:
> Greg Lehey wrote in message ID
> <[EMAIL PROTECTED]>:
>> 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 [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to