Re: gvinum remains broken in 5.3-RELEASE?

From: Andy Farkas (andy_at_bradfieldprichard.com.au)
Date: 11/08/04

  • Next message: David Xu: "Re: [FreeBSD 5.3-RC2] Processes STILL hanging in unkillable state" 
    Date: Mon, 8 Nov 2004 10:32:50 +1100 (EST)
To: Matthias Schuendehuette <msch@snafu.de>

    On Sun, 7 Nov 2004, Matthias Schuendehuette wrote:

    > RAID5 under 5.3-RELEASE (UP)
    > only works with 'classic' vinum if loaded *after* the system has come
    > up.
    >
    > Perhaps this posting could be a template for the ERRATA entry... :-)

    I can confirm that 'classic' vinum will panic if loaded before other non-
    vinum partitions are mounted. (on a 5.3-STABLE SMP box).

    This is not too encouraging either:

    > man gvinum
    No manual entry for gvinum

    :(

    Right now I am in the middle of replacing a dead disk in my 'classic'
    vinum raid5 volume. Thinking that now might be a good time to check
    out gvinum, I tried this command (despite the above message):

    # gvinum load
    unknown command 'load'
    #

    ...but geom_vinum loaded anyways! But it got it wrong :(
    The following, which appeared in /var/log/all.log, should
    all be the same subdisk name. It looks like gvinum found
    some old volume info.. I have used both volume names, but
    now should only be one (holden):

    Nov 8 09:13:08 <kern.crit> hummer kernel: GEOM_VINUM: subdisk hewey.p0.s2 is up
    Nov 8 09:13:08 <kern.crit> hummer kernel: GEOM_VINUM: subdisk hewey.p0.s1 is up
    Nov 8 09:13:09 <kern.crit> hummer kernel: GEOM_VINUM: subdisk holden.p0.s7 is up
    Nov 8 09:13:09 <kern.crit> hummer kernel: GEOM_VINUM: subdisk holden.p0.s6 is up
    Nov 8 09:13:09 <kern.crit> hummer kernel: GEOM_VINUM: subdisk holden.p0.s3 is up
    Nov 8 09:13:09 <kern.crit> hummer kernel: GEOM_VINUM: subdisk holden.p0.s2 is up
    Nov 8 09:13:09 <kern.crit> hummer kernel: GEOM_VINUM: subdisk holden.p0.s5 is up
    Nov 8 09:13:09 <kern.crit> hummer kernel: GEOM_VINUM: subdisk holden.p0.s4 is up
    Nov 8 09:13:09 <kern.crit> hummer kernel: GEOM_VINUM: subdisk holden.p0.s0 is up

    (ps. why is this a 'kern.critical' error?)

    and now it looks like I can't get rid of gvinum to go back and try
    'classic' vinum:

    # kldstat
    Id Refs Address Size Name
      1 4 0xc0400000 2bd7e0 kernel
      2 1 0xc1af1000 2000 green_saver.ko
      3 1 0xc1dfa000 10000 geom_vinum.ko
    # kldunload geom_vinum
    kldunload: can't unload file: Operation not supported
    # gvinum unload
    unknown command 'unload'
    #

    Oh well.. reboot, here we come..

    -andyf

    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: David Xu: "Re: [FreeBSD 5.3-RC2] Processes STILL hanging in unkillable state"

    Relevant Pages

    • Re: FreeBSD 5.x raid...
      ... vinum in all commands. ... Also, as mentioned before, gvinum is not yet feature complete so some of the ... things listed in the documentation for vinum doesn't work yet. ... I can't say how gmirror differs ...
      (freebsd-questions)
    • Re: Vinum configuration lost at vinum stop / start
      ... While 5.3 is IMHO pretty stable, gvinum is quite new ... > So if you need a critically stable vinum environment you would be better off ... <ACPI PCI bus> on pcib0 ... atapci1: port ...
      (freebsd-questions)
    • Re: vinum or gvinum
      ... do _NOT_ use vinum on 5.4, use gvinum. ... sd length 2080m drive pain ...
      (freebsd-stable)
    • Re: software raid survey
      ... > dump/restore to move /home from the mirror to the stripe. ... Anyways, i agree with you, vinum is extraordinary flexible and powerful, ... In the case of gvinum there is the further problem that only a small ...
      (comp.unix.bsd.freebsd.misc)
    • vinum or gvinum
      ... this is vinum v gvinum. ... Mounting root from ufs:/dev/gvinum/root ... Tried to configure the same with gvinum replicating the vinum.conf, ... Please note that whilst best efforts are made, neither the company nor the sender accepts any responsibility for viruses and it is your responsibility to scan the email and attachments. ...
      (freebsd-stable)