From jeremie at le-hen.org Thu Jul 3 06:47:39 2008 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Thu Jul 3 06:47:43 2008 Subject: GMirror problem updating from FreeBSD 6.2 to 7.0 In-Reply-To: References: <722jk9fo.1214219192.4360070.andrea@ragedrecords.com> Message-ID: <20080703060929.GA79324@obiwan.tataz.chchile.org> Hi Andrea, On Mon, Jun 23, 2008 at 12:08:59PM +0100, Andrea Brancatelli wrote: > On 6/23/2008, "Andrea Brancatelli" wrote: > > [.....] > > >What should I do? Maybe write a new bsdlabel and hope it matches the > >previous one (it should as I think) > > Should I try to restart the old 6.2 installation and see if it can see > the mirror? > > Maybe I should try to mount the partition directly bypassing the mirror? > > Thank you very much for your help, the situation's pretty much > critical... You can use "gmirror clear " to remove the metadata, so it won't be tasted as a gmirror component anymore. Don't forget to "stop" the mirror first. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From bugmaster at FreeBSD.org Mon Jul 7 11:06:59 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 7 11:08:06 2008 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200807071106.m67B6wod062035@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/73177 geom kldload geom_* causes panic due to memory exhaustion o kern/84556 geom [geom] GBDE-encrypted swap causes panic at shutdown o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo s kern/89102 geom [geom] [panic] panic when forced unmount FS from unplu o kern/89546 geom [geom] GEOM error a kern/89660 geom [vinum] [patch] [panic] due to g_malloc returning null o bin/90093 geom fdisk(8) incapable of altering in-core geometry o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/113419 geom [geom] geom fox multipathing not failing back o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/120021 geom net-p2p/qbittorrent crashes system when it works thoug o kern/120231 geom [geom] GEOM_CONCAT error adding second drive o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/122067 geom [panic]: Geom crashed during boot f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/123122 geom [geom] GEOM / gjournal kernel lock o kern/123962 geom [panic] gjournal(8): gjournal (455Gb data, 8Gb journal o kern/124130 geom [gmirror][usb] gmirror fails to start usb devices that o kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s 22 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/78131 geom gbde(8) "destroy" not working. o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113885 geom [gmirror] [patch] improved gmirror balance algorithm o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile f kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/119743 geom [geom] geom label for cds is keeped after dismount and o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/123630 geom [patch] [gmirror] gmirror doesnt allow the original dr o misc/124434 geom [UPDATING] [patch]: Missing UPDATING entry for geom mi o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con 16 problems total. From remko at FreeBSD.org Mon Jul 7 11:40:45 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Mon Jul 7 11:40:52 2008 Subject: misc/124434: [UPDATING] [patch]: Missing UPDATING entry for geom mirror metadata version rev Message-ID: <200807071140.m67Bei7p069973@freefall.freebsd.org> Synopsis: [UPDATING] [patch]: Missing UPDATING entry for geom mirror metadata version rev Responsible-Changed-From-To: freebsd-geom->remko Responsible-Changed-By: remko Responsible-Changed-When: Mon Jul 7 11:40:44 UTC 2008 Responsible-Changed-Why: I'll take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=124434 From lulf at stud.ntnu.no Wed Jul 9 17:40:06 2008 From: lulf at stud.ntnu.no (Ulf Lilleengen) Date: Wed Jul 9 17:40:13 2008 Subject: kern/124969: gvinum(8): gvinum raid5 plex does not detect missing subdisk Message-ID: <200807091740.m69He5M6056322@freefall.freebsd.org> The following reply was made to PR kern/124969; it has been noted by GNATS. From: Ulf Lilleengen To: bug-followup@FreeBSD.org, drkp-f@ambulatoryclam.net Cc: Subject: Re: kern/124969: gvinum(8): gvinum raid5 plex does not detect missing subdisk Date: Wed, 9 Jul 2008 19:38:24 +0200 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, I think I managed to solve the issue, at least it works in CURRENT. This patch is for RELENG_6, but I've not been able to test it. Be careful, I make no guarantees of what it will do :) However, it doesn't touch any data, just handles some extra fields and flags in the structures. I ended up making it possible to have "referenced" drives (drives with no real device), as well as subdisks that didn't have a "real" drive yet. Also, I fixed some issues with the plex states when things are tasted, but please be careful and watch the states and make sure they are what they "should" be (E.g. a failed drive that is returning should neved have the UP state, since it must be synchronized first). I even found a "real" bug in CURRENT while making this patch as well. Please tell me how it fares. -- Ulf Lilleengen --gBBFr7Ir9EOA20Yy Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="gvinum_detect_down_disk.diff" Index: sys/geom/vinum/geom_vinum_drive.c =================================================================== --- sys/geom/vinum/geom_vinum_drive.c (revision 180387) +++ sys/geom/vinum/geom_vinum_drive.c (working copy) @@ -476,6 +476,13 @@ */ d = gv_find_drive(sc, vhdr->label.name); + /* If it's referenced, remove it before we re-create it. */ + if (d != NULL && d->flags & GV_DRIVE_REFERENCED) { + LIST_REMOVE(d, drive); + g_free(d); + d = NULL; + } + /* We already know about this drive. */ if (d != NULL) { /* Check if this drive already has a geom. */ @@ -536,10 +543,12 @@ * them. */ LIST_FOREACH(s, &sc->subdisks, sd) { - if (!strncmp(s->drive, d->name, GV_MAXDRIVENAME)) + if (!strncmp(s->drive, d->name, GV_MAXDRIVENAME)) { /* XXX: errors ignored */ gv_sd_to_drive(sc, d, s, errstr, sizeof(errstr)); + s->flags &= ~GV_SD_NODRIVE; + } } /* This drive is now up for sure. */ Index: sys/geom/vinum/geom_vinum_list.c =================================================================== --- sys/geom/vinum/geom_vinum_list.c (revision 180387) +++ sys/geom/vinum/geom_vinum_list.c (working copy) @@ -314,6 +314,8 @@ i = 0; LIST_FOREACH(s, &p->subdisks, in_plex) { sbuf_printf(sb, "\t\tSubdisk %d:\t%s\n", i, s->name); + if (s->flags & GV_SD_NODRIVE) + continue; sbuf_printf(sb, "\t\t state: %s\tsize %11jd " "(%jd MB)\n", gv_sdstate(s->state), (intmax_t)s->size, (intmax_t)s->size / MEGABYTE); @@ -361,6 +363,12 @@ { if (flags & GV_FLAG_V) { sbuf_printf(sb, "Subdisk %s:\n", s->name); + if (s->flags & GV_SD_NODRIVE) { + sbuf_printf(sb, "\t\tSize: 0 bytes (0 MB)\n"); + sbuf_printf(sb, "\t\tState: %s\n", + gv_sdstate(s->state)); + return; + } sbuf_printf(sb, "\t\tSize: %16jd bytes (%jd MB)\n", (intmax_t)s->size, (intmax_t)s->size / MEGABYTE); sbuf_printf(sb, "\t\tState: %s\n", gv_sdstate(s->state)); @@ -390,6 +398,11 @@ gv_roughlength(s->drive_offset, 1)); } else { sbuf_printf(sb, "S %-21s State: ", s->name); + if (s->flags & GV_SD_NODRIVE) { + sbuf_printf(sb, "%s\t", gv_sdstate(s->state)); + sbuf_printf(sb, "D: %-12s Size: 0\n", s->drive); + return; + } if (s->state == GV_SD_INITIALIZING || s->state == GV_SD_REVIVING) { if (s->state == GV_SD_INITIALIZING) @@ -439,6 +452,8 @@ /* Verbose listing. */ if (flags & GV_FLAG_V) { sbuf_printf(sb, "Drive %s:\tDevice %s\n", d->name, d->device); + if (d->flags & GV_DRIVE_REFERENCED) + return; sbuf_printf(sb, "\t\tSize: %16jd bytes (%jd MB)\n", (intmax_t)d->size, (intmax_t)d->size / MEGABYTE); sbuf_printf(sb, "\t\tUsed: %16jd bytes (%jd MB)\n", @@ -458,8 +473,13 @@ (intmax_t)fl->offset, (intmax_t)fl->size); } } else { - sbuf_printf(sb, "D %-21s State: %s\t/dev/%s\tA: %jd/%jd MB " - "(%d%%)\n", d->name, gv_drivestate(d->state), d->device, + sbuf_printf(sb, "D %-21s State: %s\t/dev/%s\t", d->name, + gv_drivestate(d->state), d->device); + if (d->flags & GV_DRIVE_REFERENCED) { + sbuf_printf(sb, "\n"); + return; + } + sbuf_printf(sb, "A: %jd/%jd MB (%d%%)\n", (intmax_t)d->avail / MEGABYTE, (intmax_t)d->size / MEGABYTE, (int)((d->avail * 100) / d->size)); } Index: sys/geom/vinum/geom_vinum_subr.c =================================================================== --- sys/geom/vinum/geom_vinum_subr.c (revision 180387) +++ sys/geom/vinum/geom_vinum_subr.c (working copy) @@ -87,6 +87,7 @@ struct gv_volume *v, *v2; struct gv_plex *p, *p2; struct gv_sd *s, *s2; + struct gv_drive *d; int tokens; char *token[GV_MAXARGS]; @@ -144,6 +145,7 @@ p->vinumconf = sc; LIST_INIT(&p->subdisks); + LIST_INIT(&p->delayed_sd); LIST_INSERT_HEAD(&sc->plexes, p, plex); } else if (!strcmp(token[0], "sd")) { @@ -154,6 +156,28 @@ break; } + /* The drive might not exist. */ + d = gv_find_drive(sc, s->drive); + if (d == NULL) { + s->flags |= GV_SD_NODRIVE; + s->state = GV_SD_DOWN; + d = g_malloc(sizeof(struct gv_drive), + M_WAITOK | M_ZERO); + d->state = GV_DRIVE_DOWN; + d->flags |= GV_DRIVE_REFERENCED; + strlcpy(d->name, s->drive, + GV_MAXDRIVENAME); + s->drive_sc = d; + snprintf(d->device, GV_MAXDRIVENAME, + "???"); + LIST_INSERT_HEAD(&sc->drives, d, drive); + p = gv_find_plex(sc, s->plex); + if (p != NULL) { + /* Register delayed plex. */ + LIST_INSERT_HEAD(&p->delayed_sd, + s, in_plex_delay); + } + } if (merge) { s2 = gv_find_sd(sc, s->name); if (s2 != NULL) { @@ -236,9 +260,10 @@ } int -gv_sd_to_plex(struct gv_plex *p, struct gv_sd *s, int check) +gv_sd_to_plex(struct gv_plex *p, struct gv_sd *s, int check, int taste) { struct gv_sd *s2; + struct gv_drive *d; g_topology_assert(); @@ -246,6 +271,13 @@ if (s->plex_sc == p) return (0); + /* If we're coming from a taste, mark the subdisk up if drive is up. */ + if (taste) { + d = gv_find_drive(p->vinumconf, s->drive); + if (d->state = GV_DRIVE_UP) + gv_set_sd_state(s, GV_SD_UP, GV_SETSTATE_FORCE); + } + /* Find the correct plex offset for this subdisk, if needed. */ if (s->plex_offset == -1) { if (p->sdcount) { @@ -325,7 +357,7 @@ { struct gv_sd *s, *s2; off_t remainder; - int required_sds, state; + int required_sds, state, sdcount; KASSERT(p != NULL, ("gv_update_plex_config: NULL p")); @@ -349,10 +381,18 @@ break; } + sdcount = p->sdcount; + LIST_FOREACH(s2, &p->subdisks, in_plex) { + if (s2->flags & GV_SD_NODRIVE) + sdcount--; + } if (required_sds) { - if (p->sdcount < required_sds) { + if (sdcount < required_sds) { state = GV_PLEX_DOWN; } + if ((sdcount == (required_sds - 1)) && + (p->org == GV_PLEX_RAID5)) { + state = GV_PLEX_DEGRADED; /* * The subdisks in striped plexes must all have the same size. @@ -412,8 +452,9 @@ s->state = GV_SD_STALE; p->flags &= ~GV_PLEX_ADDED; p->flags &= ~GV_PLEX_NEWBORN; - p->state = GV_PLEX_DOWN; + state = GV_PLEX_DOWN; } + p->state = state; } /* @@ -441,7 +482,7 @@ errlen)); /* Check if this subdisk was already given to this drive. */ - if (s->drive_sc == d) + if (s->drive_sc == d && !(s->flags & GV_SD_NODRIVE)) return (0); /* Preliminary checks. */ Index: sys/geom/vinum/geom_vinum.c =================================================================== --- sys/geom/vinum/geom_vinum.c (revision 180387) +++ sys/geom/vinum/geom_vinum.c (working copy) @@ -248,6 +248,7 @@ p->vinumconf = sc; p->flags |= GV_PLEX_NEWBORN; LIST_INIT(&p->subdisks); + LIST_INIT(&p->delayed_sd); LIST_INSERT_HEAD(&sc->plexes, p, plex); } @@ -302,7 +303,7 @@ * Then, we give the subdisk to the plex; we check if the * given values are correct and maybe adjust them. */ - error = gv_sd_to_plex(p, s, 1); + error = gv_sd_to_plex(p, s, 1, 0); if (error) { printf("FOO: couldn't give sd '%s' to plex '%s'\n", s->name, p->name); Index: sys/geom/vinum/geom_vinum_state.c =================================================================== --- sys/geom/vinum/geom_vinum_state.c (revision 180387) +++ sys/geom/vinum/geom_vinum_state.c (working copy) @@ -171,7 +171,8 @@ case GV_SD_UP: /* We can't bring the subdisk up if our drive is dead. */ d = s->drive_sc; - if ((d == NULL) || (d->state != GV_DRIVE_UP)) + if ((d == NULL) || (d->state != GV_DRIVE_UP) || + (d->flags & GV_DRIVE_REFERENCED)) return (-1); /* Check from where we want to be brought up. */ @@ -276,6 +277,8 @@ s->flags &= ~GV_SD_NEWBORN; } else if (s->state != GV_SD_UP) s->state = GV_SD_STALE; + else if (s->flags & GV_SD_NODRIVE) + s->state = GV_SD_DOWN; else s->state = GV_SD_UP; @@ -391,6 +394,10 @@ p->sddown++; /* XXX: Another unusable subdisk? */ break; } + if (s->flags & GV_SD_NODRIVE) + p->sddown++; } + LIST_FOREACH(s, &p->delayed_sd, in_plex_delay) + p->sddown++; return (statemap); } Index: sys/geom/vinum/geom_vinum.h =================================================================== --- sys/geom/vinum/geom_vinum.h (revision 180387) +++ sys/geom/vinum/geom_vinum.h (working copy) @@ -86,7 +86,7 @@ void gv_parse_config(struct gv_softc *, u_char *, int); int gv_sd_to_drive(struct gv_softc *, struct gv_drive *, struct gv_sd *, char *, int); -int gv_sd_to_plex(struct gv_plex *, struct gv_sd *, int); +int gv_sd_to_plex(struct gv_plex *, struct gv_sd *, int, int); void gv_update_plex_config(struct gv_plex *); void gv_update_vol_size(struct gv_volume *, off_t); Index: sys/geom/vinum/geom_vinum_var.h =================================================================== --- sys/geom/vinum/geom_vinum_var.h (revision 180387) +++ sys/geom/vinum/geom_vinum_var.h (working copy) @@ -190,6 +190,7 @@ #define GV_DRIVE_THREAD_DIE 0x02 /* Signal the worker thread to die. */ #define GV_DRIVE_THREAD_DEAD 0x04 /* The worker thread has died. */ #define GV_DRIVE_NEWBORN 0x08 /* The drive was just created. */ +#define GV_DRIVE_REFERENCED 0x10 /* The drive does not yet exist. */ struct gv_hdr *hdr; /* The drive header. */ @@ -226,6 +227,7 @@ int flags; #define GV_SD_NEWBORN 0x01 /* Subdisk was just created. */ #define GV_SD_INITCANCEL 0x02 /* Cancel initialization process. */ +#define GV_SD_NODRIVE 0x04 /* The subdisk does'nt have a drive. */ char drive[GV_MAXDRIVENAME]; /* Name of underlying drive. */ char plex[GV_MAXPLEXNAME]; /* Name of associated plex. */ @@ -239,6 +241,7 @@ LIST_ENTRY(gv_sd) from_drive; /* Subdisk list of underlying drive. */ LIST_ENTRY(gv_sd) in_plex; /* Subdisk list of associated plex. */ LIST_ENTRY(gv_sd) sd; /* Entry in the vinum config. */ + LIST_ENTRY(gv_sd) in_plex_delay; /* Delayed entry. */ struct gv_softc *vinumconf; /* Pointer to the vinum config. */ }; @@ -281,6 +284,7 @@ TAILQ_HEAD(,gv_bioq) wqueue; /* Waiting BIO queue. */ TAILQ_HEAD(,gv_raid5_packet) packets; /* RAID5 sub-requests. */ + LIST_HEAD(,gv_sd) delayed_sd; /* List of delayed subdisks. */ LIST_HEAD(,gv_sd) subdisks; /* List of attached subdisks. */ LIST_ENTRY(gv_plex) in_volume; /* Plex list of associated volume. */ LIST_ENTRY(gv_plex) plex; /* Entry in the vinum config. */ Index: sys/geom/vinum/geom_vinum_move.c =================================================================== --- sys/geom/vinum/geom_vinum_move.c (revision 180387) +++ sys/geom/vinum/geom_vinum_move.c (working copy) @@ -190,7 +190,7 @@ } } - gv_sd_to_plex(p, newsd, 1); + gv_sd_to_plex(p, newsd, 1, 0); /* Creates the new providers.... */ gv_drive_modify(d); Index: sys/geom/vinum/geom_vinum_plex.c =================================================================== --- sys/geom/vinum/geom_vinum_plex.c (revision 180387) +++ sys/geom/vinum/geom_vinum_plex.c (working copy) @@ -273,7 +273,7 @@ { struct bio *bp; struct gv_plex *p; - struct gv_sd *s; + struct gv_sd *s, *s2; struct gv_bioq *bq; p = arg; @@ -285,6 +285,17 @@ if (p->flags & GV_PLEX_THREAD_DIE) break; + /* First make sure we got all subdisks. */ + LIST_FOREACH_SAFE(s, &p->delayed_sd, in_plex_delay, s2) { + if (s->flags & GV_SD_NODRIVE) { + gv_set_sd_state(s, GV_SD_STALE, + GV_SETSTATE_FORCE); + } + gv_sd_to_plex(p, s, 0, 0); + LIST_REMOVE(s, in_plex_delay); + gv_update_plex_config(p); + } + /* Take the first BIO from our queue. */ bq = TAILQ_FIRST(&p->bqueue); if (bq == NULL) { @@ -737,7 +748,7 @@ * configuration, we don't check the given value (should we?). * XXX: shouldn't be done here */ - gv_sd_to_plex(p, s, 0); + gv_sd_to_plex(p, s, 0, 1); /* Now check if there's already a geom for this plex. */ gp = p->geom; --gBBFr7Ir9EOA20Yy-- From lulf at stud.ntnu.no Wed Jul 9 17:50:03 2008 From: lulf at stud.ntnu.no (Ulf Lilleengen) Date: Wed Jul 9 17:50:09 2008 Subject: kern/124969: gvinum(8): gvinum raid5 plex does not detect missing subdisk Message-ID: <200807091750.m69Ho3Hk056590@freefall.freebsd.org> The following reply was made to PR kern/124969; it has been noted by GNATS. From: Ulf Lilleengen To: bug-followup@FreeBSD.org, drkp-f@ambulatoryclam.net Cc: Subject: Re: kern/124969: gvinum(8): gvinum raid5 plex does not detect missing subdisk Date: Wed, 9 Jul 2008 19:49:07 +0200 Hi again, I also put the patch here: http://people.freebsd.org/~lulf/patches/gvinum/gvinum_detect_down_disk.diff In case you love GNATS as much as I do :) -- Ulf Lilleengen From tapan.list at gmail.com Thu Jul 10 12:55:15 2008 From: tapan.list at gmail.com (Tapan Chaudhari) Date: Thu Jul 10 12:55:22 2008 Subject: Can GEOM be used to intercept the I/o calls to an existing mounted device? Message-ID: <482257ad0807100541s2d2c3d1eo6cd57c3a1bc338d1@mail.gmail.com> Hi All, I am a newbie to FreeBSD and GEOM. I wanted to intercept the i/o calls going to a particular mounted device by writing some driver. I came across geom and thought it might work. I tried to create a new device, mount it and then tried using gmirror to mirror the device :- #dd if=/dev/zero of=file1 bs=1M count=10 #dd if=/dev/zero of=file2 bs=1M count=10 #mdconfig -f file1 #mdconfig -f file2 #fdisk -B /dev/mirror/md0 #newfs /dev/mirror/md0s1 #mkdir /mnt/mirror0 #mount /dev/mirror/md0s1 /mnt/mirror0/ #gmirror label -v -n -b round-robin gm0 /dev/md0 gmirror: Can't store metadata on /dev/md0: Operation not permitted. It gave me this error "gmirror: Can't store metadata on /dev/md0: Operation not permitted." Am I doing something wrong? Or GEOM does not permit me intercept the i/o calls? If not geom, is there any other mechanism by which I can achieve it? Thanks, --Tapan. From mark at legios.org Thu Jul 10 13:33:34 2008 From: mark at legios.org (Mark Gladman) Date: Thu Jul 10 13:33:43 2008 Subject: Can GEOM be used to intercept the I/o calls to an existing mounted device? In-Reply-To: <482257ad0807100541s2d2c3d1eo6cd57c3a1bc338d1@mail.gmail.com> References: <482257ad0807100541s2d2c3d1eo6cd57c3a1bc338d1@mail.gmail.com> Message-ID: <200807102309.03191.mark@legios.org> On Thursday 10 July 2008 22:41:25 Tapan Chaudhari wrote: > Hi All, > I am a newbie to FreeBSD and GEOM. I wanted to intercept the i/o calls > going to a particular mounted device by writing some driver. > I came across geom and thought it might work. I tried to create a new > device, mount it and then tried using gmirror to mirror the device :- > > #dd if=/dev/zero of=file1 bs=1M count=10 > #dd if=/dev/zero of=file2 bs=1M count=10 > #mdconfig -f file1 > #mdconfig -f file2 > #fdisk -B /dev/mirror/md0 > #newfs /dev/mirror/md0s1 > #mkdir /mnt/mirror0 > #mount /dev/mirror/md0s1 /mnt/mirror0/ > > #gmirror label -v -n -b round-robin gm0 /dev/md0 > gmirror: Can't store metadata on /dev/md0: Operation not permitted. > > It gave me this error "gmirror: Can't store metadata on /dev/md0: Operation > not permitted." > > Am I doing something wrong? Or GEOM does not permit me intercept the i/o > calls? If not geom, is there any other mechanism by which I can achieve it? > > > Thanks, > --Tapan. > _______________________________________________ > freebsd-geom@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-geom > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" Hey, You're attempting to set up gmirror on a mounted device. Unmount /dev/mirror/md0s1 then retry the gmirror command and it should work. Cheers! Mark From tapan.list at gmail.com Thu Jul 10 13:55:42 2008 From: tapan.list at gmail.com (Tapan Chaudhari) Date: Thu Jul 10 13:55:49 2008 Subject: Can GEOM be used to intercept the I/o calls to an existing mounted device? In-Reply-To: <200807102309.03191.mark@legios.org> References: <482257ad0807100541s2d2c3d1eo6cd57c3a1bc338d1@mail.gmail.com> <200807102309.03191.mark@legios.org> Message-ID: <482257ad0807100655u1a5c660awfad05564e40e9a95@mail.gmail.com> Thanks Mark, but unmounting will anyways work. But the problem here will be, a new device "/dev/mirror/gm0" and "/dev/mirror/gm0s1" will be created after :- #gmirror label -v -n -b round-robin gm0 /dev/md0 #gmirror load #gmirror configure -a gm0 and "/dev/md0s1" gets deleted. Now I will have to mount the new device "/dev/mirror/gm0s1" to get my original contents. Can't I do it on the fly while the device is already mounted? I just want that all the calls going to the device "/dev/md0s1" first come to me and then it goes to the original device. In short intercepting the i/o calls. Is there some way I can achieve this? Thanks, On Thu, Jul 10, 2008 at 6:39 PM, Mark Gladman wrote: > On Thursday 10 July 2008 22:41:25 Tapan Chaudhari wrote: > > Hi All, > > I am a newbie to FreeBSD and GEOM. I wanted to intercept the i/o > calls > > going to a particular mounted device by writing some driver. > > I came across geom and thought it might work. I tried to create a new > > device, mount it and then tried using gmirror to mirror the device :- > > > > #dd if=/dev/zero of=file1 bs=1M count=10 > > #dd if=/dev/zero of=file2 bs=1M count=10 > > #mdconfig -f file1 > > #mdconfig -f file2 > > #fdisk -B /dev/mirror/md0 > > #newfs /dev/mirror/md0s1 > > #mkdir /mnt/mirror0 > > #mount /dev/mirror/md0s1 /mnt/mirror0/ > > > > #gmirror label -v -n -b round-robin gm0 /dev/md0 > > gmirror: Can't store metadata on /dev/md0: Operation not permitted. > > > > It gave me this error "gmirror: Can't store metadata on /dev/md0: > Operation > > not permitted." > > > > Am I doing something wrong? Or GEOM does not permit me intercept the i/o > > calls? If not geom, is there any other mechanism by which I can achieve > it? > > > > > > Thanks, > > --Tapan. > > _______________________________________________ > > freebsd-geom@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-geom > > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" > > Hey, > > You're attempting to set up gmirror on a mounted device. > Unmount /dev/mirror/md0s1 then retry the gmirror command and it should > work. > > Cheers! > Mark > From mark at legios.org Thu Jul 10 14:42:17 2008 From: mark at legios.org (Mark Gladman) Date: Thu Jul 10 14:42:24 2008 Subject: Can GEOM be used to intercept the I/o calls to an existing mounted device? In-Reply-To: <482257ad0807100655u1a5c660awfad05564e40e9a95@mail.gmail.com> References: <482257ad0807100541s2d2c3d1eo6cd57c3a1bc338d1@mail.gmail.com> <200807102309.03191.mark@legios.org> <482257ad0807100655u1a5c660awfad05564e40e9a95@mail.gmail.com> Message-ID: <200807110039.42114.mark@legios.org> Ah, I see what you mean... Not as far as I'm aware - although there's people here much more knowledgeable on the subject than me. You can write the geom metadata to the mounted disk(s) by settings the following sysctl kern.geom.debugflags=16 (This is potentially unsafe, but for what you're doing it should be fine) Out of curiosities sake though, I did the follwing. (note - I had to do this on a zvol on this workstation, so hopefully it's not invalid) mount /dev/zvol/zpool0/test /mnt sysctl kern.geom.debugflags=16 gmirror label -v -n -b round-robin gm0 /dev/zvol/zpool0/test kldload geom_mirror However, if I then do mount /dev/mirror/test0 /mnt2 Then do *anything* involving /mnt2, it causes FreeBSD to keel over - not totally unexpected. I'm not sure if this helps - hopefully others can chime in. On Thursday 10 July 2008 23:55:40 Tapan Chaudhari wrote: > Thanks Mark, but unmounting will anyways work. But the problem here will > be, a new device "/dev/mirror/gm0" and "/dev/mirror/gm0s1" will be created > after > > :- > > #gmirror label -v -n -b round-robin gm0 /dev/md0 > #gmirror load > #gmirror configure -a gm0 > > and "/dev/md0s1" gets deleted. > Now I will have to mount the new device "/dev/mirror/gm0s1" to get my > original contents. > Can't I do it on the fly while the device is already mounted? I just want > that all the calls going to the device "/dev/md0s1" first come to me and > then it goes to the original device. In short intercepting the i/o calls. > Is there some way I can achieve this? > > Thanks, > > On Thu, Jul 10, 2008 at 6:39 PM, Mark Gladman wrote: > > On Thursday 10 July 2008 22:41:25 Tapan Chaudhari wrote: > > > Hi All, > > > I am a newbie to FreeBSD and GEOM. I wanted to intercept the i/o > > > > calls > > > > > going to a particular mounted device by writing some driver. > > > I came across geom and thought it might work. I tried to create a new > > > device, mount it and then tried using gmirror to mirror the device :- > > > > > > #dd if=/dev/zero of=file1 bs=1M count=10 > > > #dd if=/dev/zero of=file2 bs=1M count=10 > > > #mdconfig -f file1 > > > #mdconfig -f file2 > > > #fdisk -B /dev/mirror/md0 > > > #newfs /dev/mirror/md0s1 > > > #mkdir /mnt/mirror0 > > > #mount /dev/mirror/md0s1 /mnt/mirror0/ > > > > > > #gmirror label -v -n -b round-robin gm0 /dev/md0 > > > gmirror: Can't store metadata on /dev/md0: Operation not permitted. > > > > > > It gave me this error "gmirror: Can't store metadata on /dev/md0: > > > > Operation > > > > > not permitted." > > > > > > Am I doing something wrong? Or GEOM does not permit me intercept the > > > i/o calls? If not geom, is there any other mechanism by which I can > > > achieve > > > > it? > > > > > Thanks, > > > --Tapan. > > > _______________________________________________ > > > freebsd-geom@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-geom > > > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" > > > > Hey, > > > > You're attempting to set up gmirror on a mounted device. > > Unmount /dev/mirror/md0s1 then retry the gmirror command and it should > > work. > > > > Cheers! > > Mark > > _______________________________________________ > freebsd-geom@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-geom > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" From ivoras at freebsd.org Thu Jul 10 19:19:54 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Jul 10 19:20:01 2008 Subject: Can GEOM be used to intercept the I/o calls to an existing mounted device? In-Reply-To: <482257ad0807100655u1a5c660awfad05564e40e9a95@mail.gmail.com> References: <482257ad0807100541s2d2c3d1eo6cd57c3a1bc338d1@mail.gmail.com> <200807102309.03191.mark@legios.org> <482257ad0807100655u1a5c660awfad05564e40e9a95@mail.gmail.com> Message-ID: Tapan Chaudhari wrote: > Can't I do it on the fly while the device is already mounted? I just want > that all the calls going to the device "/dev/md0s1" first come to me and > then it goes to the original device. In short intercepting the i/o calls. Is > there some way I can achieve this? It would be very nice if GEOM could do this, since it would then trivially allow things like data replication, log/rollback, etc. but it doesn't work like that. In short, no, you cannot listen to IO between providers. (not that it isn't possible to do at all, it just isn't implemented). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20080710/b5581458/signature.pgp From phk at phk.freebsd.dk Thu Jul 10 22:02:37 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu Jul 10 22:02:44 2008 Subject: Can GEOM be used to intercept the I/o calls to an existing mounted device? In-Reply-To: Your message of "Thu, 10 Jul 2008 21:19:35 +0200." Message-ID: <50705.1215727354@critter.freebsd.dk> In message , Ivan Voras writes: >> Can't I do it on the fly while the device is already mounted? I just wa= >nt >> that all the calls going to the device "/dev/md0s1" first come to me an= >d >> then it goes to the original device. In short intercepting the i/o call= >s. Is >> there some way I can achieve this? > >It would be very nice if GEOM could do this, since it would then=20 >trivially allow things like data replication, log/rollback, etc. but it=20 >doesn't work like that. In short, no, you cannot listen to IO between=20 >providers. > >(not that it isn't possible to do at all, it just isn't implemented). The GEOM design allows for insertions, where a 1:1 GEOM class is inserted in an existing provider-consumer connection. The traditional example was: insert mirror module add disk to mirror replicate drop original disk from mirror remove mirror module. I may still have the code that can do this in a src tree somewhere, but it never got to the surface of my TODO list. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From mark at legios.org Thu Jul 10 23:42:35 2008 From: mark at legios.org (Mark Gladman) Date: Thu Jul 10 23:42:41 2008 Subject: Can GEOM be used to intercept the I/o calls to an existing mounted device? In-Reply-To: References: <482257ad0807100541s2d2c3d1eo6cd57c3a1bc338d1@mail.gmail.com> <482257ad0807100655u1a5c660awfad05564e40e9a95@mail.gmail.com> Message-ID: <200807110940.05862.mark@legios.org> On Friday 11 July 2008 05:19:35 Ivan Voras wrote: > Tapan Chaudhari wrote: > > Can't I do it on the fly while the device is already mounted? I just want > > that all the calls going to the device "/dev/md0s1" first come to me and > > then it goes to the original device. In short intercepting the i/o calls. > > Is there some way I can achieve this? > > It would be very nice if GEOM could do this, since it would then > trivially allow things like data replication, log/rollback, etc. but it > doesn't work like that. In short, no, you cannot listen to IO between > providers. > > (not that it isn't possible to do at all, it just isn't implemented). Whoops - I was *totally* focussing on the wrong part of his question... (It was late, that's my excuse. :) From tapan.list at gmail.com Fri Jul 11 18:29:11 2008 From: tapan.list at gmail.com (Tapan Chaudhari) Date: Fri Jul 11 18:29:17 2008 Subject: Can GEOM be used to intercept the I/o calls to an existing mounted device? In-Reply-To: <482257ad0807100655u1a5c660awfad05564e40e9a95@mail.gmail.com> References: <482257ad0807100541s2d2c3d1eo6cd57c3a1bc338d1@mail.gmail.com> <200807102309.03191.mark@legios.org> <482257ad0807100655u1a5c660awfad05564e40e9a95@mail.gmail.com> Message-ID: <482257ad0807111129i66ac4372sbc9b4d4ef7675e9d@mail.gmail.com> Hey guys, First of all, I was not able to receive your replies to my mail. I don't know the reason but I am already subscribed to the list. I got to know about your replies from the digest i received today. I have written a mail to the mailing list owner describing this problem. Hope this does not happen again. Well regarding GEOM as Poul mentioned he has already done this interception mechanism in GEOM, Poul can you please help me out by giving some directions as to how to move ahead and implement the interceptions of i/o to a particular device? I would be really happy to get any help regarding the interception mechanism. Thanks, --Tapan. On Thu, Jul 10, 2008 at 7:25 PM, Tapan Chaudhari wrote: > Thanks Mark, but unmounting will anyways work. But the problem here will > be, a new device "/dev/mirror/gm0" and "/dev/mirror/gm0s1" will be created > after :- > > #gmirror label -v -n -b round-robin gm0 /dev/md0 > #gmirror load > #gmirror configure -a gm0 > > and "/dev/md0s1" gets deleted. > Now I will have to mount the new device "/dev/mirror/gm0s1" to get my > original contents. > Can't I do it on the fly while the device is already mounted? I just want > that all the calls going to the device "/dev/md0s1" first come to me and > then it goes to the original device. In short intercepting the i/o calls. Is > there some way I can achieve this? > > Thanks, > > > On Thu, Jul 10, 2008 at 6:39 PM, Mark Gladman wrote: > >> On Thursday 10 July 2008 22:41:25 Tapan Chaudhari wrote: >> > Hi All, >> > I am a newbie to FreeBSD and GEOM. I wanted to intercept the i/o >> calls >> > going to a particular mounted device by writing some driver. >> > I came across geom and thought it might work. I tried to create a new >> > device, mount it and then tried using gmirror to mirror the device :- >> > >> > #dd if=/dev/zero of=file1 bs=1M count=10 >> > #dd if=/dev/zero of=file2 bs=1M count=10 >> > #mdconfig -f file1 >> > #mdconfig -f file2 >> > #fdisk -B /dev/mirror/md0 >> > #newfs /dev/mirror/md0s1 >> > #mkdir /mnt/mirror0 >> > #mount /dev/mirror/md0s1 /mnt/mirror0/ >> > >> > #gmirror label -v -n -b round-robin gm0 /dev/md0 >> > gmirror: Can't store metadata on /dev/md0: Operation not permitted. >> > >> > It gave me this error "gmirror: Can't store metadata on /dev/md0: >> Operation >> > not permitted." >> > >> > Am I doing something wrong? Or GEOM does not permit me intercept the i/o >> > calls? If not geom, is there any other mechanism by which I can achieve >> it? >> > >> > >> > Thanks, >> > --Tapan. >> > _______________________________________________ >> > freebsd-geom@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-geom >> > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" >> >> Hey, >> >> You're attempting to set up gmirror on a mounted device. >> Unmount /dev/mirror/md0s1 then retry the gmirror command and it should >> work. >> >> Cheers! >> Mark >> > > From tapan.list at gmail.com Fri Jul 11 19:09:05 2008 From: tapan.list at gmail.com (Tapan Chaudhari) Date: Fri Jul 11 19:09:11 2008 Subject: Can GEOM be used to intercept the I/o calls to an existing mounted device? In-Reply-To: <482257ad0807111129i66ac4372sbc9b4d4ef7675e9d@mail.gmail.com> References: <482257ad0807100541s2d2c3d1eo6cd57c3a1bc338d1@mail.gmail.com> <200807102309.03191.mark@legios.org> <482257ad0807100655u1a5c660awfad05564e40e9a95@mail.gmail.com> <482257ad0807111129i66ac4372sbc9b4d4ef7675e9d@mail.gmail.com> Message-ID: <482257ad0807111209g20cdb0f6j9f7000fd57a7287a@mail.gmail.com> Hi, I got the problem resolved of not getting mails. It was the stupid of me that changed the settings :-).. I have unchecked the digest. Did Ivan sent some attachment with the mail? An attachment was scrubbed in the digest I received. Sorry for the trouble but still, can anyone resend it? Expecting some help regarding "interception mechanism" from all of you. Thanks, --Tapan. On Fri, Jul 11, 2008 at 11:59 PM, Tapan Chaudhari wrote: > Hey guys, > First of all, I was not able to receive your replies to my mail. I > don't know the reason but I am already subscribed to the list. I got to know > about your replies from the digest i received today. I have written a mail > to the mailing list owner describing this problem. Hope this does not happen > again. > > > Well regarding GEOM as Poul mentioned he has already done this interception > mechanism in GEOM, Poul can you please help me out by giving some directions > as to how to move ahead and implement the interceptions of i/o to a > particular device? I would be really happy to get any help regarding the > interception mechanism. > > Thanks, > --Tapan. > > > On Thu, Jul 10, 2008 at 7:25 PM, Tapan Chaudhari > wrote: > >> Thanks Mark, but unmounting will anyways work. But the problem here will >> be, a new device "/dev/mirror/gm0" and "/dev/mirror/gm0s1" will be created >> after :- >> >> #gmirror label -v -n -b round-robin gm0 /dev/md0 >> #gmirror load >> #gmirror configure -a gm0 >> >> and "/dev/md0s1" gets deleted. >> Now I will have to mount the new device "/dev/mirror/gm0s1" to get my >> original contents. >> Can't I do it on the fly while the device is already mounted? I just want >> that all the calls going to the device "/dev/md0s1" first come to me and >> then it goes to the original device. In short intercepting the i/o calls. Is >> there some way I can achieve this? >> >> Thanks, >> >> >> On Thu, Jul 10, 2008 at 6:39 PM, Mark Gladman wrote: >> >>> On Thursday 10 July 2008 22:41:25 Tapan Chaudhari wrote: >>> > Hi All, >>> > I am a newbie to FreeBSD and GEOM. I wanted to intercept the i/o >>> calls >>> > going to a particular mounted device by writing some driver. >>> > I came across geom and thought it might work. I tried to create a new >>> > device, mount it and then tried using gmirror to mirror the device :- >>> > >>> > #dd if=/dev/zero of=file1 bs=1M count=10 >>> > #dd if=/dev/zero of=file2 bs=1M count=10 >>> > #mdconfig -f file1 >>> > #mdconfig -f file2 >>> > #fdisk -B /dev/mirror/md0 >>> > #newfs /dev/mirror/md0s1 >>> > #mkdir /mnt/mirror0 >>> > #mount /dev/mirror/md0s1 /mnt/mirror0/ >>> > >>> > #gmirror label -v -n -b round-robin gm0 /dev/md0 >>> > gmirror: Can't store metadata on /dev/md0: Operation not permitted. >>> > >>> > It gave me this error "gmirror: Can't store metadata on /dev/md0: >>> Operation >>> > not permitted." >>> > >>> > Am I doing something wrong? Or GEOM does not permit me intercept the >>> i/o >>> > calls? If not geom, is there any other mechanism by which I can achieve >>> it? >>> > >>> > >>> > Thanks, >>> > --Tapan. >>> > _______________________________________________ >>> > freebsd-geom@freebsd.org mailing list >>> > http://lists.freebsd.org/mailman/listinfo/freebsd-geom >>> > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org >>> " >>> >>> Hey, >>> >>> You're attempting to set up gmirror on a mounted device. >>> Unmount /dev/mirror/md0s1 then retry the gmirror command and it should >>> work. >>> >>> Cheers! >>> Mark >>> >> >> > From kris at FreeBSD.org Sun Jul 13 00:58:24 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Sun Jul 13 00:58:29 2008 Subject: GEOM_STRIPE device wackiness Message-ID: <4879532F.7000603@FreeBSD.org> I tried to create a stripe on two disks, after writing a new label to overwrite the previous one (all filesystems and swap had been unconfigured). No slices were in use on the disk and I did gstripe label -v -s 131072 data /dev/da0d /dev/da1d newfs worked fine, etc. Rebooted, and geom decided my da0 needed to sprout a da0s1, and that the gstripe should attach there (actually the da0? devices were completely gone). The filesystem was corrupt because the offsets were now all wrong on one of the disks. Rebooting into single-user mode the devices were sort of back: # ls -l /dev/da0* crw-r----- 1 root operator 0, 74 Jul 13 00:48 /dev/da0 crw-r----- 1 root operator 0, 76 Jul 13 00:48 /dev/da0b crw-r----- 1 root operator 0, 77 Jul 13 00:48 /dev/da0c crw-r----- 1 root operator 0, 83 Jul 13 00:48 /dev/da0cs1 crw-r----- 1 root operator 0, 87 Jul 13 00:48 /dev/da0cs1b crw-r----- 1 root operator 0, 88 Jul 13 00:48 /dev/da0cs1c crw-r----- 1 root operator 0, 89 Jul 13 00:48 /dev/da0cs1d crw-r----- 1 root operator 0, 78 Jul 13 00:48 /dev/da0d crw-r----- 1 root operator 0, 79 Jul 13 00:48 /dev/da0s1 crw-r----- 1 root operator 0, 84 Jul 13 00:48 /dev/da0s1b crw-r----- 1 root operator 0, 85 Jul 13 00:48 /dev/da0s1c crw-r----- 1 root operator 0, 86 Jul 13 00:48 /dev/da0s1d "da0cs1"? Uh ok. # bsdlabel -r /dev/da0 # /dev/da0: 8 partitions: # size offset fstype [fsize bsize bps/cpg] b: 33554432 16 swap c: 143638992 0 unused 0 0 # "raw" part, don't edit d: 110084544 33554448 4.2BSD 0 0 0 ...still looks fine # gstripe destroy data GEOM_STRIPE: Disk da0d removed from data. GEOM_STRIPE: Device data destroyed. # gstripe label -v -s 131072 -h data /dev/da0d /dev/da1d GEOM_STRIPE: Device data created (id=2560258567). GEOM_STRIPE: Disk da0s1d attached to data. GEOM_STRIPE: Disk da0s1d removed from data. GEOM_STRIPE: Device data destroyed. GEOM_STRIPE: Device data created (id=476052638). GEOM_STRIPE: Disk da0d attached to data. GEOM_STRIPE: Device data already configured. GEOM_STRIPE: Cannot create device data. Metadata value stored on da0d. GEOM_STRIPE: Disk da1d attached to data. GEOM_STRIPE: Device data activated. Metadata value stored on da1d. Done. Why all this craziness? Now I can mount the filesystem again, but still: # ls -l /dev/da0* crw-r----- 1 root operator 0, 74 Jul 13 00:48 /dev/da0 crw-r----- 1 root operator 0, 76 Jul 13 00:48 /dev/da0b crw-r----- 1 root operator 0, 77 Jul 13 00:48 /dev/da0c crw-r----- 1 root operator 0, 83 Jul 13 00:48 /dev/da0cs1 crw-r----- 1 root operator 0, 87 Jul 13 00:48 /dev/da0cs1b crw-r----- 1 root operator 0, 88 Jul 13 00:48 /dev/da0cs1c crw-r----- 1 root operator 0, 89 Jul 13 00:48 /dev/da0cs1d crw-r----- 1 root operator 0, 78 Jul 13 00:49 /dev/da0d What's going on here? Kris From bugmaster at FreeBSD.org Mon Jul 14 11:06:58 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 14 11:07:46 2008 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200807141106.m6EB6vSD014413@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/73177 geom kldload geom_* causes panic due to memory exhaustion o kern/84556 geom [geom] GBDE-encrypted swap causes panic at shutdown o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo s kern/89102 geom [geom] [panic] panic when forced unmount FS from unplu o kern/89546 geom [geom] GEOM error a kern/89660 geom [vinum] [patch] [panic] due to g_malloc returning null o bin/90093 geom fdisk(8) incapable of altering in-core geometry o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/113419 geom [geom] geom fox multipathing not failing back o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/120021 geom net-p2p/qbittorrent crashes system when it works thoug o kern/120231 geom [geom] GEOM_CONCAT error adding second drive o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/122067 geom [panic]: Geom crashed during boot f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/123122 geom [geom] GEOM / gjournal kernel lock o kern/123962 geom [panic] gjournal(8): gjournal (455Gb data, 8Gb journal o kern/124130 geom [gmirror][usb] gmirror fails to start usb devices that o kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s 22 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/78131 geom gbde(8) "destroy" not working. o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113885 geom [gmirror] [patch] improved gmirror balance algorithm o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile f kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/119743 geom [geom] geom label for cds is keeped after dismount and o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/123630 geom [patch] [gmirror] gmirror doesnt allow the original dr o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con 15 problems total. From tapan.list at gmail.com Mon Jul 14 19:05:09 2008 From: tapan.list at gmail.com (Tapan Chaudhari) Date: Mon Jul 14 19:05:15 2008 Subject: Can GEOM be used to intercept the I/o calls to an existing mounted device? In-Reply-To: <482257ad0807111209g20cdb0f6j9f7000fd57a7287a@mail.gmail.com> References: <482257ad0807100541s2d2c3d1eo6cd57c3a1bc338d1@mail.gmail.com> <200807102309.03191.mark@legios.org> <482257ad0807100655u1a5c660awfad05564e40e9a95@mail.gmail.com> <482257ad0807111129i66ac4372sbc9b4d4ef7675e9d@mail.gmail.com> <482257ad0807111209g20cdb0f6j9f7000fd57a7287a@mail.gmail.com> Message-ID: <482257ad0807141205i1d5e2c2co4b609a9f5b7015b@mail.gmail.com> Hi All, I am not able to find ways to intercept the i/o calls. I will need your help to move ahead. One thing to mention is 'mirror' is just an example. I want to write a new driver which will intercept the i/o calls. This is the first major milestone to achieve. Needed your help. Any pointers and directions will do. Thanks, --Tapan. On Sat, Jul 12, 2008 at 12:39 AM, Tapan Chaudhari wrote: > Hi, > I got the problem resolved of not getting mails. It was the stupid of me > that changed the settings :-).. I have unchecked the digest. > > Did Ivan sent some attachment with the mail? An attachment was scrubbed in > the digest I received. Sorry for the trouble but still, can anyone resend > it? > Expecting some help regarding "interception mechanism" from all of you. > > > Thanks, > --Tapan. > > > On Fri, Jul 11, 2008 at 11:59 PM, Tapan Chaudhari > wrote: > >> Hey guys, >> First of all, I was not able to receive your replies to my mail. I >> don't know the reason but I am already subscribed to the list. I got to know >> about your replies from the digest i received today. I have written a mail >> to the mailing list owner describing this problem. Hope this does not happen >> again. >> >> >> Well regarding GEOM as Poul mentioned he has already done this >> interception mechanism in GEOM, Poul can you please help me out by giving >> some directions as to how to move ahead and implement the interceptions of >> i/o to a particular device? I would be really happy to get any help >> regarding the interception mechanism. >> >> Thanks, >> --Tapan. >> >> >> On Thu, Jul 10, 2008 at 7:25 PM, Tapan Chaudhari >> wrote: >> >>> Thanks Mark, but unmounting will anyways work. But the problem here will >>> be, a new device "/dev/mirror/gm0" and "/dev/mirror/gm0s1" will be created >>> after :- >>> >>> #gmirror label -v -n -b round-robin gm0 /dev/md0 >>> #gmirror load >>> #gmirror configure -a gm0 >>> >>> and "/dev/md0s1" gets deleted. >>> Now I will have to mount the new device "/dev/mirror/gm0s1" to get my >>> original contents. >>> Can't I do it on the fly while the device is already mounted? I just want >>> that all the calls going to the device "/dev/md0s1" first come to me and >>> then it goes to the original device. In short intercepting the i/o calls. Is >>> there some way I can achieve this? >>> >>> Thanks, >>> >>> >>> On Thu, Jul 10, 2008 at 6:39 PM, Mark Gladman wrote: >>> >>>> On Thursday 10 July 2008 22:41:25 Tapan Chaudhari wrote: >>>> > Hi All, >>>> > I am a newbie to FreeBSD and GEOM. I wanted to intercept the i/o >>>> calls >>>> > going to a particular mounted device by writing some driver. >>>> > I came across geom and thought it might work. I tried to create a new >>>> > device, mount it and then tried using gmirror to mirror the device :- >>>> > >>>> > #dd if=/dev/zero of=file1 bs=1M count=10 >>>> > #dd if=/dev/zero of=file2 bs=1M count=10 >>>> > #mdconfig -f file1 >>>> > #mdconfig -f file2 >>>> > #fdisk -B /dev/mirror/md0 >>>> > #newfs /dev/mirror/md0s1 >>>> > #mkdir /mnt/mirror0 >>>> > #mount /dev/mirror/md0s1 /mnt/mirror0/ >>>> > >>>> > #gmirror label -v -n -b round-robin gm0 /dev/md0 >>>> > gmirror: Can't store metadata on /dev/md0: Operation not permitted. >>>> > >>>> > It gave me this error "gmirror: Can't store metadata on /dev/md0: >>>> Operation >>>> > not permitted." >>>> > >>>> > Am I doing something wrong? Or GEOM does not permit me intercept the >>>> i/o >>>> > calls? If not geom, is there any other mechanism by which I can >>>> achieve it? >>>> > >>>> > >>>> > Thanks, >>>> > --Tapan. >>>> > _______________________________________________ >>>> > freebsd-geom@freebsd.org mailing list >>>> > http://lists.freebsd.org/mailman/listinfo/freebsd-geom >>>> > To unsubscribe, send any mail to " >>>> freebsd-geom-unsubscribe@freebsd.org" >>>> >>>> Hey, >>>> >>>> You're attempting to set up gmirror on a mounted device. >>>> Unmount /dev/mirror/md0s1 then retry the gmirror command and it should >>>> work. >>>> >>>> Cheers! >>>> Mark >>>> >>> >>> >> > From gavin at FreeBSD.org Tue Jul 15 17:08:40 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Tue Jul 15 17:08:52 2008 Subject: kern/125632: [gvinum] rename does not work for drive objects Message-ID: <200807151708.m6FH8eJm009490@freefall.freebsd.org> Old Synopsis: gvinum rename does not work for drive objects New Synopsis: [gvinum] rename does not work for drive objects Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: gavin Responsible-Changed-When: Tue Jul 15 17:08:04 UTC 2008 Responsible-Changed-Why: Over to maintainers http://www.freebsd.org/cgi/query-pr.cgi?pr=125632 From kris at FreeBSD.org Tue Jul 15 21:01:52 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Tue Jul 15 21:01:59 2008 Subject: GEOM_STRIPE device wackiness In-Reply-To: <4879532F.7000603@FreeBSD.org> References: <4879532F.7000603@FreeBSD.org> Message-ID: <487D1041.70702@FreeBSD.org> Kris Kennaway wrote: > I tried to create a stripe on two disks, after writing a new label to > overwrite the previous one (all filesystems and swap had been > unconfigured). No slices were in use on the disk and I did > > gstripe label -v -s 131072 data /dev/da0d /dev/da1d > > newfs worked fine, etc. Rebooted, and geom decided my da0 needed to > sprout a da0s1, and that the gstripe should attach there (actually the > da0? devices were completely gone). The filesystem was corrupt because > the offsets were now all wrong on one of the disks. > > Rebooting into single-user mode the devices were sort of back: > > # ls -l /dev/da0* > crw-r----- 1 root operator 0, 74 Jul 13 00:48 /dev/da0 > crw-r----- 1 root operator 0, 76 Jul 13 00:48 /dev/da0b > crw-r----- 1 root operator 0, 77 Jul 13 00:48 /dev/da0c > crw-r----- 1 root operator 0, 83 Jul 13 00:48 /dev/da0cs1 > crw-r----- 1 root operator 0, 87 Jul 13 00:48 /dev/da0cs1b > crw-r----- 1 root operator 0, 88 Jul 13 00:48 /dev/da0cs1c > crw-r----- 1 root operator 0, 89 Jul 13 00:48 /dev/da0cs1d > crw-r----- 1 root operator 0, 78 Jul 13 00:48 /dev/da0d > crw-r----- 1 root operator 0, 79 Jul 13 00:48 /dev/da0s1 > crw-r----- 1 root operator 0, 84 Jul 13 00:48 /dev/da0s1b > crw-r----- 1 root operator 0, 85 Jul 13 00:48 /dev/da0s1c > crw-r----- 1 root operator 0, 86 Jul 13 00:48 /dev/da0s1d > > "da0cs1"? Uh ok. > > # bsdlabel -r /dev/da0 > # /dev/da0: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > b: 33554432 16 swap > c: 143638992 0 unused 0 0 # "raw" part, > don't edit > d: 110084544 33554448 4.2BSD 0 0 0 > > ...still looks fine > > # gstripe destroy data > GEOM_STRIPE: Disk da0d removed from data. > GEOM_STRIPE: Device data destroyed. > # gstripe label -v -s 131072 -h data /dev/da0d /dev/da1d > GEOM_STRIPE: Device data created (id=2560258567). > GEOM_STRIPE: Disk da0s1d attached to data. > GEOM_STRIPE: Disk da0s1d removed from data. > GEOM_STRIPE: Device data destroyed. > GEOM_STRIPE: Device data created (id=476052638). > GEOM_STRIPE: Disk da0d attached to data. > GEOM_STRIPE: Device data already configured. > GEOM_STRIPE: Cannot create device data. > Metadata value stored on da0d. > GEOM_STRIPE: Disk da1d attached to data. > GEOM_STRIPE: Device data activated. > Metadata value stored on da1d. > Done. > > Why all this craziness? > > Now I can mount the filesystem again, but still: > > # ls -l /dev/da0* > crw-r----- 1 root operator 0, 74 Jul 13 00:48 /dev/da0 > crw-r----- 1 root operator 0, 76 Jul 13 00:48 /dev/da0b > crw-r----- 1 root operator 0, 77 Jul 13 00:48 /dev/da0c > crw-r----- 1 root operator 0, 83 Jul 13 00:48 /dev/da0cs1 > crw-r----- 1 root operator 0, 87 Jul 13 00:48 /dev/da0cs1b > crw-r----- 1 root operator 0, 88 Jul 13 00:48 /dev/da0cs1c > crw-r----- 1 root operator 0, 89 Jul 13 00:48 /dev/da0cs1d > crw-r----- 1 root operator 0, 78 Jul 13 00:49 /dev/da0d > > What's going on here? > > Kris > More wackiness: > # gstripe destroy disk > GEOM_STRIPE: Disk da0d removed from disk. > GEOM_STRIPE: Device disk removed. > GEOM_STRIPE: Disk da1d removed from disk. > GEOM_STRIPE: Device disk destroyed. > # gstripe clear da0 > Can't clear metadata on da0: Operation not permitted. > gstripe: Not fully done. > # swapoff /dev/da0b > # gstripe clear da0 > GEOM_STRIPE: Device disk created (id=4082191315). > GEOM_STRIPE: Disk da0d attached to disk. > Can't clear metadata on da0: Invalid argument. > gstripe: Not fully done. (whee my stripe is back) > # dd if=/dev/zero of=/dev/da0 bs=1m count=16 > GEOM_STRIPE: Disk da0d removed from disk. > GEOM_STRIPE: Device disk removed. > 16+0 records in > 16+0 records out > 16777216 bytes transferred in 1.307623 secs (12830317 bytes/sec) Kris From lulf at FreeBSD.org Wed Jul 16 06:02:33 2008 From: lulf at FreeBSD.org (lulf@FreeBSD.org) Date: Wed Jul 16 06:02:39 2008 Subject: kern/125632: [gvinum] rename does not work for drive objects Message-ID: <200807160602.m6G62XMi080757@freefall.freebsd.org> Synopsis: [gvinum] rename does not work for drive objects Responsible-Changed-From-To: freebsd-geom->lulf Responsible-Changed-By: lulf Responsible-Changed-When: Wed Jul 16 06:01:41 UTC 2008 Responsible-Changed-Why: - I'll look at this later today. http://www.freebsd.org/cgi/query-pr.cgi?pr=125632 From pjd at FreeBSD.org Fri Jul 18 09:50:21 2008 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Fri Jul 18 09:50:44 2008 Subject: GEOM_STRIPE device wackiness In-Reply-To: <4879532F.7000603@FreeBSD.org> References: <4879532F.7000603@FreeBSD.org> Message-ID: <20080714064120.GA13560@garage.freebsd.pl> On Sun, Jul 13, 2008 at 02:58:23AM +0200, Kris Kennaway wrote: > I tried to create a stripe on two disks, after writing a new label to > overwrite the previous one (all filesystems and swap had been > unconfigured). No slices were in use on the disk and I did > > gstripe label -v -s 131072 data /dev/da0d /dev/da1d > > newfs worked fine, etc. Rebooted, and geom decided my da0 needed to > sprout a da0s1, and that the gstripe should attach there (actually the > da0? devices were completely gone). The filesystem was corrupt because > the offsets were now all wrong on one of the disks. > > Rebooting into single-user mode the devices were sort of back: > > # ls -l /dev/da0* > crw-r----- 1 root operator 0, 74 Jul 13 00:48 /dev/da0 > crw-r----- 1 root operator 0, 76 Jul 13 00:48 /dev/da0b > crw-r----- 1 root operator 0, 77 Jul 13 00:48 /dev/da0c > crw-r----- 1 root operator 0, 83 Jul 13 00:48 /dev/da0cs1 > crw-r----- 1 root operator 0, 87 Jul 13 00:48 /dev/da0cs1b > crw-r----- 1 root operator 0, 88 Jul 13 00:48 /dev/da0cs1c > crw-r----- 1 root operator 0, 89 Jul 13 00:48 /dev/da0cs1d > crw-r----- 1 root operator 0, 78 Jul 13 00:48 /dev/da0d > crw-r----- 1 root operator 0, 79 Jul 13 00:48 /dev/da0s1 > crw-r----- 1 root operator 0, 84 Jul 13 00:48 /dev/da0s1b > crw-r----- 1 root operator 0, 85 Jul 13 00:48 /dev/da0s1c > crw-r----- 1 root operator 0, 86 Jul 13 00:48 /dev/da0s1d > > "da0cs1"? Uh ok. > > # bsdlabel -r /dev/da0 > # /dev/da0: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > b: 33554432 16 swap > c: 143638992 0 unused 0 0 # "raw" part, > don't edit > d: 110084544 33554448 4.2BSD 0 0 0 > > ...still looks fine > > # gstripe destroy data > GEOM_STRIPE: Disk da0d removed from data. > GEOM_STRIPE: Device data destroyed. > # gstripe label -v -s 131072 -h data /dev/da0d /dev/da1d > GEOM_STRIPE: Device data created (id=2560258567). > GEOM_STRIPE: Disk da0s1d attached to data. > GEOM_STRIPE: Disk da0s1d removed from data. > GEOM_STRIPE: Device data destroyed. > GEOM_STRIPE: Device data created (id=476052638). > GEOM_STRIPE: Disk da0d attached to data. > GEOM_STRIPE: Device data already configured. > GEOM_STRIPE: Cannot create device data. > Metadata value stored on da0d. > GEOM_STRIPE: Disk da1d attached to data. > GEOM_STRIPE: Device data activated. > Metadata value stored on da1d. > Done. > > Why all this craziness? > > Now I can mount the filesystem again, but still: > > # ls -l /dev/da0* > crw-r----- 1 root operator 0, 74 Jul 13 00:48 /dev/da0 > crw-r----- 1 root operator 0, 76 Jul 13 00:48 /dev/da0b > crw-r----- 1 root operator 0, 77 Jul 13 00:48 /dev/da0c > crw-r----- 1 root operator 0, 83 Jul 13 00:48 /dev/da0cs1 > crw-r----- 1 root operator 0, 87 Jul 13 00:48 /dev/da0cs1b > crw-r----- 1 root operator 0, 88 Jul 13 00:48 /dev/da0cs1c > crw-r----- 1 root operator 0, 89 Jul 13 00:48 /dev/da0cs1d > crw-r----- 1 root operator 0, 78 Jul 13 00:49 /dev/da0d > > What's going on here? Most likely trash BSD label metadata. Try doing: # dd if=/dev/zero of=/dev/da0 count=79 first and then bsdlabel and gstripe it again. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20080718/6b93e236/attachment.pgp From bugmaster at FreeBSD.org Mon Jul 21 11:06:55 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 21 11:07:39 2008 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200807211106.m6LB6tpd031867@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/73177 geom kldload geom_* causes panic due to memory exhaustion o kern/84556 geom [geom] GBDE-encrypted swap causes panic at shutdown o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo s kern/89102 geom [geom] [panic] panic when forced unmount FS from unplu o kern/89546 geom [geom] GEOM error a kern/89660 geom [vinum] [patch] [panic] due to g_malloc returning null o bin/90093 geom fdisk(8) incapable of altering in-core geometry o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/113419 geom [geom] geom fox multipathing not failing back o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/120021 geom net-p2p/qbittorrent crashes system when it works thoug o kern/120231 geom [geom] GEOM_CONCAT error adding second drive o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/122067 geom [panic]: Geom crashed during boot f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/123122 geom [geom] GEOM / gjournal kernel lock o kern/123962 geom [panic] gjournal(8): gjournal (455Gb data, 8Gb journal o kern/124130 geom [gmirror][usb] gmirror fails to start usb devices that o kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s 22 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/78131 geom gbde(8) "destroy" not working. o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113885 geom [gmirror] [patch] improved gmirror balance algorithm o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile f kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/119743 geom [geom] geom label for cds is keeped after dismount and o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/123630 geom [patch] [gmirror] gmirror doesnt allow the original dr o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con 15 problems total. From xd888cc7541309c3f at f4n.org Tue Jul 22 19:57:16 2008 From: xd888cc7541309c3f at f4n.org (Pete) Date: Tue Jul 22 19:57:25 2008 Subject: Moving GELI to an oversized provider Message-ID: <20080722193136.GA12642@lore.f4n.org> Due to an operator error (posted to freebsd-questions a week ago, "Using RocketRAID 1810A (hptmv) as an ordinary controller?") I have ended up with a bunch of disks having GELI inside a GEOM labeled provider, but everything offset 10 sectors from the end of the disk. That is, GEOM::ELI metadata is 11 sectors from the end of the disk and GEOM::LABEL is 10 sectors from the end. The content of the last ten sectors is unimportant and can be overwritten. In order to avoid having to rewrite all data I readded a GEOM label, placing it at the very last sector (but leaving the old one in place). I then 'geli restore':ed the GELI metadata to the newly created label, so that the end of the disk looks like: sector -1: new GEOM label sector -2: copy of old GELI metadata ... sector -10: old GEOM label sector -11: old GELI metadata This appears to be working just fine but I worry about gotchas, for instance if GELI were to access data by negative offset from the end of the provider (or would this be highly unnatural, making it unlikely even in future versions?). I notice that g_eli_taste in g_eli.c compares the stored size with the provider's size, but perhaps this is only an issue for the root file system (making it irrelevant for me)? Finally, is there a "clean" solution to this, for instance setting up an in-memory GEOM provider which references a certain slice of a disk? (Based on the documentation it appears as if NetBSD's "dkctl addwedge" does this, perhaps there is a FreeBSD equivalent.) Any comments would be appreciated! From lulf at freebsd.org Sun Jul 27 14:40:04 2008 From: lulf at freebsd.org (Ulf Lilleengen) Date: Sun Jul 27 14:40:10 2008 Subject: kern/120231: [geom] GEOM_CONCAT error adding second drive Message-ID: <200807271440.m6REe3I4037445@freefall.freebsd.org> The following reply was made to PR kern/120231; it has been noted by GNATS. From: Ulf Lilleengen To: bug-followup@FreeBSD.org, taosecurity@gmail.com Cc: Subject: Re: kern/120231: [geom] GEOM_CONCAT error adding second drive Date: Sun, 27 Jul 2008 16:34:04 +0200 Hello, As I can see it, the reason for your problem can be that since ad5s1d is spanned across the whole disk, gconcat can't see the difference between ad5s1 and ad5s1d, and thus tries to attach ad5s1 as the disk to the 'nsm' provider. (Error 17 as you get, means that the drive is already added). Could you perhaps provide bsdlabel ad5s1 output? -- Ulf Lillengen From lulf at freebsd.org Sun Jul 27 19:10:09 2008 From: lulf at freebsd.org (Ulf Lilleengen) Date: Sun Jul 27 19:10:20 2008 Subject: bin/90093: fdisk(8) incapable of altering in-core geometry Message-ID: <200807271910.m6RJA9qB060568@freefall.freebsd.org> The following reply was made to PR bin/90093; it has been noted by GNATS. From: Ulf Lilleengen To: bug-followup@FreeBSD.org Cc: Subject: Re: bin/90093: fdisk(8) incapable of altering in-core geometry Date: Sun, 27 Jul 2008 21:06:30 +0200 AFAICT, the fdisk code skips to using pwrite to write the MBR if the MBR GEOM class fails (which it will do if an MBR does not exist), and should update the MBR info correctly anyway. I was however unsuccessful altering the geometry even with this patch. But the warning printed when geom_mbr fails is a bit confusing, since the write request might be successful anyway, so we should either just quell the warning, or make using geom_mbr work. -- Ulf Lilleengen From xcllnt at mac.com Sun Jul 27 20:23:57 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Sun Jul 27 20:24:04 2008 Subject: bin/90093: fdisk(8) incapable of altering in-core geometry In-Reply-To: <200807271910.m6RJA9qB060568@freefall.freebsd.org> References: <200807271910.m6RJA9qB060568@freefall.freebsd.org> Message-ID: On Jul 27, 2008, at 12:10 PM, Ulf Lilleengen wrote: > AFAICT, the fdisk code skips to using pwrite to write the MBR if the > MBR GEOM > class fails (which it will do if an MBR does not exist), and should > update > the MBR info correctly anyway. I was however unsuccessful altering the > geometry even with this patch. But the warning printed when geom_mbr > fails is > a bit confusing, since the write request might be successful anyway, > so we > should either just quell the warning, or make using geom_mbr work. Would you mind testing gpart? Just remove GEOM_MBR from your kernel (i.e. add nooption GEOM_MBR) and add options GEOM_PART_MBR instead. -- Marcel Moolenaar xcllnt@mac.com From bugmaster at FreeBSD.org Mon Jul 28 11:06:57 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 28 11:07:45 2008 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200807281106.m6SB6uo6078905@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/73177 geom kldload geom_* causes panic due to memory exhaustion o kern/84556 geom [geom] GBDE-encrypted swap causes panic at shutdown o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo s kern/89102 geom [geom] [panic] panic when forced unmount FS from unplu o kern/89546 geom [geom] GEOM error a kern/89660 geom [vinum] [patch] [panic] due to g_malloc returning null o bin/90093 geom fdisk(8) incapable of altering in-core geometry o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/113419 geom [geom] geom fox multipathing not failing back o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/120021 geom net-p2p/qbittorrent crashes system when it works thoug o kern/120231 geom [geom] GEOM_CONCAT error adding second drive o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/122067 geom [panic]: Geom crashed during boot f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/123122 geom [geom] GEOM / gjournal kernel lock o kern/123962 geom [panic] gjournal(8): gjournal (455Gb data, 8Gb journal o kern/124130 geom [gmirror][usb] gmirror fails to start usb devices that o kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s 22 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/78131 geom gbde(8) "destroy" not working. o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113885 geom [gmirror] [patch] improved gmirror balance algorithm o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile f kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/119743 geom [geom] geom label for cds is keeped after dismount and o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/123630 geom [patch] [gmirror] gmirror doesnt allow the original dr o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con 15 problems total. From taosecurity at gmail.com Mon Jul 28 18:10:03 2008 From: taosecurity at gmail.com (Richard Bejtlich) Date: Mon Jul 28 18:10:08 2008 Subject: kern/120231: [geom] GEOM_CONCAT error adding second drive Message-ID: <200807281810.m6SIA2CG019877@freefall.freebsd.org> The following reply was made to PR kern/120231; it has been noted by GNATS. From: "Richard Bejtlich" To: "Ulf Lilleengen" Cc: bug-followup@freebsd.org Subject: Re: kern/120231: [geom] GEOM_CONCAT error adding second drive Date: Mon, 28 Jul 2008 13:35:19 -0400 On Sun, Jul 27, 2008 at 10:34 AM, Ulf Lilleengen wrote: > Hello, > > As I can see it, the reason for your problem can be that since ad5s1d is > spanned across the whole disk, gconcat can't see the difference between ad5s1 > and ad5s1d, and thus tries to attach ad5s1 as the disk to the 'nsm' provider. > (Error 17 as you get, means that the drive is already added). Could you > perhaps provide bsdlabel ad5s1 output? > > -- > Ulf Lillengen > Hi Ulf, I don't have that exact box available, but here's another box where I implemented the same workaround. # mount /dev/ad2s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad2s1e on /home (ufs, local, soft-updates) /dev/concat/nsm on /nsm (ufs, local) /dev/ad2s1f on /tmp (ufs, local, soft-updates) /dev/ad3s1d on /tmp2 (ufs, local, soft-updates) /dev/ad2s1d on /usr (ufs, local, soft-updates) /dev/ad2s1g on /var (ufs, local, soft-updates) # cat /etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/ad2s1b none swap sw 0 0 /dev/ad2s1a / ufs rw 1 1 /dev/ad2s1e /home ufs rw 2 2 #/dev/ad2s1h /nsm1 ufs rw 2 2 #/dev/ad3s1e /nsm2 ufs rw 2 2 /dev/concat/nsm /nsm ufs rw 2 2 /dev/ad2s1f /tmp ufs rw 2 2 /dev/ad3s1d /tmp2 ufs rw 2 2 /dev/ad2s1d /usr ufs rw 2 2 /dev/ad2s1g /var ufs rw 2 2 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 # bsdlabel /dev/ad3s1 # /dev/ad3s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 312496317 0 unused 0 0 # "raw" part, don't edit d: 1048576 0 4.2BSD 2048 16384 8 e: 311447741 1048576 4.2BSD 2048 16384 28552 Thank you, Richard From drkp-f at ambulatoryclam.net Tue Jul 29 00:00:12 2008 From: drkp-f at ambulatoryclam.net (Dan Ports) Date: Tue Jul 29 00:00:18 2008 Subject: kern/124969: gvinum(8): gvinum raid5 plex does not detect missing subdisk Message-ID: <200807290000.m6T00CEI052657@freefall.freebsd.org> The following reply was made to PR kern/124969; it has been noted by GNATS. From: Dan Ports To: Ulf Lilleengen Cc: bug-followup@FreeBSD.org Subject: Re: kern/124969: gvinum(8): gvinum raid5 plex does not detect missing subdisk Date: Mon, 28 Jul 2008 16:53:05 -0700 I finally got a chance to try your patch (unfortunately, work and life intervened for a couple of weeks). I had to make a minor change or two to get it to compile (e.g. a missing brace). Will provide an updated patch shortly. Unfortunately, though the missing disk is now detected, the plex configuration is not quite right. Here's the output: 3 drives: D b State: up /dev/ad11s1d A: 0/474891 MB (0%) D a State: up /dev/ad10s1d A: 0/474891 MB (0%) D c State: down /dev/??? 1 volume: V space State: up Plexes: 1 Size: 463 GB 1 plex: P space.p0 R5 State: degraded Subdisks: 2 Size: 463 GB 3 subdisks: S space.p0.s0 State: up D: a Size: 463 GB S space.p0.s1 State: stale D: b Size: 463 GB S space.p0.s2 State: down D: c Size: 0 Note that drive c / subdisk s2 are correctly missing, but the plex still contains only two subdisks and is half as large as it should be. Also, not sure why subdisk s1 is marked stale. Thanks, Dan -- Dan R. K. Ports Research Henchman Massachusetts Institute of Technology Computer Science and Artificial Intelligence Lab