From owner-freebsd-geom@FreeBSD.ORG Sun Mar 9 07:40:18 2008 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D286B1065676 for ; Sun, 9 Mar 2008 07:40:18 +0000 (UTC) (envelope-from mirror176@cox.net) Received: from fed1rmmtai105.cox.net (fed1rmmtai105.cox.net [68.230.241.55]) by mx1.freebsd.org (Postfix) with ESMTP id AEE3A8FC22 for ; Sun, 9 Mar 2008 07:40:18 +0000 (UTC) (envelope-from mirror176@cox.net) Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao104.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20080309071215.FHXM1982.fed1rmmtao104.cox.net@fed1rmimpo01.cox.net> for ; Sun, 9 Mar 2008 03:12:15 -0400 Received: from darkstar.l.net ([70.176.148.72]) by fed1rmimpo01.cox.net with bizsmtp id yvC11Y00A1ZxX6m0000000; Sun, 09 Mar 2008 03:12:01 -0400 Received: from darkstar.l.net ([127.0.0.1]) by darkstar.l.net with esmtp; Sun, 09 Mar 2008 00:12:14 -0700 id 0001CC07.47D38DCE.00015FB0 Received: from localhost (localhost [[UNIX: localhost]]) by darkstar.l.net (8.14.2/8.14.2/Submit) id m297CEwn090030 for freebsd-geom@freebsd.org; Sun, 9 Mar 2008 00:12:14 -0700 (MST) (envelope-from mirror176@cox.net) X-Authentication-Warning: darkstar.l.net: mirror176 set sender to mirror176@cox.net using -f From: "Edward Sanford Sutton, III" To: freebsd-geom@freebsd.org Date: Sun, 9 Mar 2008 00:12:13 -0700 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803090012.13711.mirror176@cox.net> Subject: gvinum raid5 consuming entire cpu on FreeBSD 7.0 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2008 07:40:18 -0000 Upgrading from 6-stable to 7.0-release has lead to a couple of immediately noticeable changes. The striped swap across 3 disks, with 1 disk having been removed and reinserted could finally be brought to an up state again with a start command; was not available when last tested on 6-stable. Within top, I've found the system process "gv_p usr.p0" taking up all cpu time on my system when there is a lot of write activity to usr.p0. The result is the system becoming almost entirely unresponsive during much of the write. An example case is when trying to build the editors/openoffice.org-2 port; when archives are being extracted, services time out connections to clients, screens stop refreshing (and top shows the system process at 100% once it starts to get a little bit of time again), mouse/keyboard input becomes bufffered and all goes through at once when some cpu time is free. The openoffice.org build running with nice 20 still causes major service interruption. The only good response I still get is switching between virtual text consoles (alt + F2, alt + F3, etc). Upgrading lead to a few changes being required in the kernel; do any of the following sound like optional changes I made that I can remove to try improving the performance: options STOP_NMI # Stop CPUS using NMI instead of IPI options AUDIT # Security event auditing options SMP # Symmetric MultiProcessor Kernel device cpufreq device uart # Generic UART driver wlan additions, although I have no wireless hardware on this machine. Any other ideas how to get the load under concrol? I remember being able to bogg down my system with an excessive mysql database fro disk load before, but do not recall reaching such cpu load with anything that it could seem the computer froze for input/output for more than a few seconds max; freezes can now go for over a minute. Thanks again, Ed Sutton From owner-freebsd-geom@FreeBSD.ORG Mon Mar 10 05:27:13 2008 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FB961065671 for ; Mon, 10 Mar 2008 05:27:13 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (keira.kiwi-computer.com [63.224.10.3]) by mx1.freebsd.org (Postfix) with SMTP id A3D638FC23 for ; Mon, 10 Mar 2008 05:27:12 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 50050 invoked by uid 2001); 10 Mar 2008 05:27:11 -0000 Date: Sun, 9 Mar 2008 23:27:11 -0600 From: "Rick C. Petty" To: freebsd-geom@freebsd.org Message-ID: <20080310052711.GA49676@keira.kiwi-computer.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: [patch] geom_vinum platform fixes X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2008 05:27:13 -0000 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Attached is a patch against RELENG_6 (but applies cleanly against RELENG_7). It contains a fix to the geom_vinum platform brokenness explained in my earlier email. Please review the patch and provide any feedback. I will try to find a committer to review/commit this and any subsequent changes early this week. Here is a quick overview of the patch. I've split the reading and writing of the on-disk vinum header into separate functions. The header is read by gv_drive_taste() and written by gv_save_config() and gv_rm_drive(). For reads, there are three possible on-disk formats it handles: the legacy i386 and legacy amd64 formats and the current (forward-going) format. The legacy formats are distinguished by the algorithm in gv_test_legacy_header_type(), which tests for known zeros, etc. Both legacy formats are stored in little-endian, and this code should work on all architectures regardless of endianness. I use a separate in-memory structure to simplify the conversions. For writes, the patch only supports the new forward-going on-disk format. This format is stored in big-endian (network order, also it's easier to read with hexdump) and uses a new magic. This new magic value contains a version number which I've started at 1, in case future enhancements are made to the on-disk structure. Note that devices with old formats are auto-upgraded when the configuration is written, which does not happen unless "gvinum saveconfig" is used or the gvinum configuration is changed for any reason. This lets admins keep using the old format. All new devices added to gvinum will get the new format. I've tested this patch on 6.3-stable (i386) and 7.0-stable (i386, amd64) systems, using vinum configurations created by amd64 & i386 formats and by the new format. Other testers are welcome! -- Rick C. Petty --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="gvinum-6.diff" --- sys/geom/vinum/geom_vinum.h.orig 2005-12-23 21:21:36.000000000 -0600 +++ sys/geom/vinum/geom_vinum.h 2008-03-09 13:50:58.000000000 -0500 @@ -32,6 +32,8 @@ #define ERRBUFSIZ 1024 /* geom_vinum_drive.c */ +struct gv_hdr *gv_read_header(struct g_consumer *cp, int *error); +int gv_write_header(struct g_consumer *cp, struct gv_hdr* hdr); void gv_config_new_drive(struct gv_drive *); void gv_drive_modify(struct gv_drive *); void gv_save_config_all(struct gv_softc *); --- sys/geom/vinum/geom_vinum_drive.c.orig 2005-12-23 21:21:36.000000000 -0600 +++ sys/geom/vinum/geom_vinum_drive.c 2008-03-09 23:12:04.000000000 -0500 @@ -29,8 +29,9 @@ __FBSDID("$FreeBSD: src/sys/geom/vinum/g #include #include -#include #include +#include +#include #include #include #include @@ -50,6 +51,169 @@ __FBSDID("$FreeBSD: src/sys/geom/vinum/g static void gv_drive_dead(void *, int); static void gv_drive_worker(void *); +int gv_test_legacy_header_type(uint8_t *); + +/* + * Here are the "offset (size)" for the various struct gv_hdr fields, + * for the legacy i386, legacy amd64, and current (cpu & endian agnostic) + * versions of the on-disk format of the vinum header structure: + * + * i386 amd64 current field + * -------- -------- -------- ----- + * 0 ( 8) 0 ( 8) 0 ( 8) magic + * 8 ( 4) 8 ( 8) 8 ( 4) config_length + * 12 (32) 16 (32) 16 (32) label.sysname + * 44 (32) 48 (32) 48 (32) label.name + * 76 ( 4) 80 ( 8) 80 ( 8) label.date_of_birth.tv_sec + * 80 ( 4) 88 ( 8) 88 ( 8) label.date_of_birth.tv_usec + * 84 ( 4) 96 ( 8) 96 ( 8) label.last_update.tv_sec + * 88 ( 4) 104 ( 8) 104 ( 8) label.last_update.tv_usec + * 92 ( 8) 112 ( 8) 112 ( 8) label.drive_size + * ======== ======== ======== + * 100 120 120 total size + * + * NOTE: i386 and amd64 formats are stored as little-endian; the current + * format uses big-endian (network order). + */ + +/* + * returns: + * 0 = legacy i386 on-disk format + * 1 = legacy amd64 on-disk format + */ +int +gv_test_legacy_header_type(uint8_t *hdr) +{ + uint32_t* i32; + int i; + + /* if non-empty hostname overlaps amd64 config_length */ + i32 = (uint32_t *)(hdr + 12); + if (*i32 != 0) + return 0; + /* check for non-empty hostname */ + if (hdr[16] != 0) + return 1; + /* check bytes past i386 structure */ + for (i = 100; i < 120; i++) + if (hdr[i] != 0) + return 1; + /* check for overlapping timestamp */ + i32 = (uint32_t *)(hdr + 84); + if (*i32 == 0) + return 1; + return 0; +} + +struct gv_hdr * +gv_read_header(struct g_consumer *cp, int *error) +{ + uint8_t *d_hdr; + struct gv_hdr *m_hdr; + int off; + +#define GV_GET32(endian) \ + endian##32toh(*((uint32_t *)&d_hdr[off])); \ + off += 4 +#define GV_GET64(endian) \ + endian##64toh(*((uint64_t *)&d_hdr[off])); \ + off += 8 + + d_hdr = g_read_data(cp, GV_HDR_OFFSET, GV_HDR_LEN, error); + if (d_hdr == NULL) + return NULL; + m_hdr = g_malloc(GV_HDR_LEN, M_WAITOK | M_ZERO); + off = 0; + m_hdr->magic = GV_GET64(be); + if (m_hdr->magic == GV_MAGIC) { + m_hdr->config_length = GV_GET32(be); + off = 16; + bcopy(d_hdr + off, m_hdr->label.sysname, GV_HOSTNAME_LEN); + off += GV_HOSTNAME_LEN; + bcopy(d_hdr + off, m_hdr->label.name, GV_MAXDRIVENAME); + off += GV_MAXDRIVENAME; + m_hdr->label.date_of_birth.tv_sec = GV_GET64(be); + m_hdr->label.date_of_birth.tv_usec = GV_GET64(be); + m_hdr->label.last_update.tv_sec = GV_GET64(be); + m_hdr->label.last_update.tv_usec = GV_GET64(be); + m_hdr->label.drive_size = GV_GET64(be); + } else if (m_hdr->magic != GV_OLD_MAGIC) { + if (error != NULL) + *error = 0; + g_free(d_hdr); + g_free(m_hdr); + return NULL; + } else if (!gv_test_legacy_header_type(d_hdr)) { + m_hdr->magic = GV_MAGIC; + /* legacy i386 on-disk header */ + m_hdr->config_length = GV_GET32(le); + bcopy(d_hdr + off, m_hdr->label.sysname, GV_HOSTNAME_LEN); + off += GV_HOSTNAME_LEN; + bcopy(d_hdr + off, m_hdr->label.name, GV_MAXDRIVENAME); + off += GV_MAXDRIVENAME; + m_hdr->label.date_of_birth.tv_sec = GV_GET32(le); + m_hdr->label.date_of_birth.tv_usec = GV_GET32(le); + m_hdr->label.last_update.tv_sec = GV_GET32(le); + m_hdr->label.last_update.tv_usec = GV_GET32(le); + m_hdr->label.drive_size = GV_GET64(le); + } else { + m_hdr->magic = GV_MAGIC; + /* legacy amd64 on-disk header */ + m_hdr->config_length = GV_GET64(le); + bcopy(d_hdr + 16, m_hdr->label.sysname, GV_HOSTNAME_LEN); + off += GV_HOSTNAME_LEN; + bcopy(d_hdr + 48, m_hdr->label.name, GV_MAXDRIVENAME); + off += GV_MAXDRIVENAME; + m_hdr->label.date_of_birth.tv_sec = GV_GET64(le); + m_hdr->label.date_of_birth.tv_usec = GV_GET64(le); + m_hdr->label.last_update.tv_sec = GV_GET64(le); + m_hdr->label.last_update.tv_usec = GV_GET64(le); + m_hdr->label.drive_size = GV_GET64(le); + } + + g_free(d_hdr); + return m_hdr; +} + +int +gv_write_header(struct g_consumer *cp, struct gv_hdr *m_hdr) +{ + uint8_t *d_hdr; + int off, ret; + +#define GV_SET32BE(field) \ + do { \ + *((uint32_t *)&d_hdr[off]) = htobe32(field); \ + off += 4; \ + } while (0) +#define GV_SET64BE(field) \ + do { \ + *((uint64_t *)&d_hdr[off]) = htobe64(field); \ + off += 8; \ + } while (0) + + KASSERT(m_hdr != NULL, ("gv_write_header: null m_hdr")); + d_hdr = g_malloc(GV_HDR_LEN, M_WAITOK | M_ZERO); + off = 0; + GV_SET64BE(m_hdr->magic); + GV_SET32BE(m_hdr->config_length); + off = 16; + bcopy(m_hdr->label.sysname, d_hdr + off, GV_HOSTNAME_LEN); + off += GV_HOSTNAME_LEN; + bcopy(m_hdr->label.name, d_hdr + off, GV_MAXDRIVENAME); + off += GV_MAXDRIVENAME; + GV_SET64BE(m_hdr->label.date_of_birth.tv_sec); + GV_SET64BE(m_hdr->label.date_of_birth.tv_usec); + GV_SET64BE(m_hdr->label.last_update.tv_sec); + GV_SET64BE(m_hdr->label.last_update.tv_usec); + GV_SET64BE(m_hdr->label.drive_size); + + ret = g_write_data(cp, GV_HDR_OFFSET, d_hdr, GV_HDR_LEN); + g_free(d_hdr); + return ret; +} + + void gv_config_new_drive(struct gv_drive *d) { @@ -156,7 +320,7 @@ gv_save_config(struct g_consumer *cp, st g_topology_unlock(); do { - error = g_write_data(cp2, GV_HDR_OFFSET, vhdr, GV_HDR_LEN); + error = gv_write_header(cp2, vhdr); if (error) { printf("GEOM_VINUM: writing vhdr failed on drive %s, " "errno %d", d->name, error); @@ -452,7 +616,7 @@ gv_drive_taste(struct g_class *mp, struc /* Now check if the provided slice is a valid vinum drive. */ do { - vhdr = g_read_data(cp, GV_HDR_OFFSET, pp->sectorsize, NULL); + vhdr = gv_read_header(cp, NULL); if (vhdr == NULL) break; if (vhdr->magic != GV_MAGIC) { --- sys/geom/vinum/geom_vinum_rm.c.orig 2005-12-23 21:21:36.000000000 -0600 +++ sys/geom/vinum/geom_vinum_rm.c 2008-03-09 13:41:42.000000000 -0500 @@ -304,7 +304,7 @@ gv_rm_drive(struct gv_softc *sc, struct /* Clear the Vinum Magic. */ d->hdr->magic = GV_NOMAGIC; g_topology_unlock(); - err = g_write_data(cp, GV_HDR_OFFSET, d->hdr, GV_HDR_LEN); + err = gv_write_header(cp, d->hdr); if (err) { printf("GEOM_VINUM: gv_rm_drive: couldn't write header to '%s'" ", errno: %d\n", cp->provider->name, err); --- sys/geom/vinum/geom_vinum_var.h.orig 2005-08-19 03:48:04.000000000 -0500 +++ sys/geom/vinum/geom_vinum_var.h 2008-03-09 22:22:56.000000000 -0500 @@ -136,10 +136,13 @@ struct gv_label { /* The 'header' of each valid vinum drive. */ struct gv_hdr { uint64_t magic; -#define GV_MAGIC 22322600044678729LL -#define GV_NOMAGIC 22322600044678990LL +#define GV_OLD_MAGIC 0x494E2056494E4F00LL +#define GV_OLD_NOMAGIC 0x4E4F2056494E4F00LL +#define GV_MAGIC 0x56494E554D2D3100LL +#define GV_NOMAGIC 0x56494E554D2D2D00LL +#define GV_VERSION(hdrp) ((((gv)->magic >> 8) & 127) - 48) - int config_length; + uint64_t config_length; struct gv_label label; }; --7AUc2qLy4jB3hD7Z-- From owner-freebsd-geom@FreeBSD.ORG Mon Mar 10 11:07:03 2008 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 137E81065673 for ; Mon, 10 Mar 2008 11:07:02 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 184628FC1B for ; Mon, 10 Mar 2008 11:07:02 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2AB71gj086542 for ; Mon, 10 Mar 2008 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2AB71Pu086538 for freebsd-geom@FreeBSD.org; Mon, 10 Mar 2008 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Mar 2008 11:07:01 GMT Message-Id: <200803101107.m2AB71Pu086538@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-geom@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2008 11:07:03 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/73177 geom kldload geom_* causes panic due to memory exhaustion o kern/76538 geom [gbde] nfs-write on gbde partition stalls and continue o kern/83464 geom [geom] [patch] Unhandled malloc failures within libgeo 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_vfs] [panic] panic when forced unmount FS from u o bin/90093 geom fdisk(8) incapable of altering in-core geometry o kern/90582 geom [geom_mirror] [panic] Restore cause panic string (ffs_ 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/115572 geom [gbde] [patch] gbde partitions fail at 28bit/48bit LBA o kern/120021 geom net-p2p/qbittorrent crashes system when it works thoug o kern/120231 geom [geom] GEOM_CONCAT error adding second drive f kern/121364 geom [gmirror] Removing all providers create a "zombie" mir 16 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/78131 geom gbde "destroy" not working. 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 control utility does not exit with correct exi o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113885 geom [geom] [patch] improved gmirror balance algorithm o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile o 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 f kern/120091 geom [geom] [geli] [gjournal] geli does not prompt for pass 12 problems total. From owner-freebsd-geom@FreeBSD.ORG Mon Mar 10 13:27:49 2008 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40571106566C; Mon, 10 Mar 2008 13:27:49 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2BAD08FC13; Mon, 10 Mar 2008 13:27:49 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2ADRmf7004511; Mon, 10 Mar 2008 13:27:48 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2ADRmHw004507; Mon, 10 Mar 2008 13:27:48 GMT (envelope-from linimon) Date: Mon, 10 Mar 2008 13:27:48 GMT Message-Id: <200803101327.m2ADRmHw004507@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-geom@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/121559: [patch] [geom] geom label class allows to create inaccessible labels X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2008 13:27:49 -0000 Synopsis: [patch] [geom] geom label class allows to create inaccessible labels Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: linimon Responsible-Changed-When: Mon Mar 10 13:27:39 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=121559 From owner-freebsd-geom@FreeBSD.ORG Mon Mar 10 13:40:05 2008 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E6D31065672 for ; Mon, 10 Mar 2008 13:40:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 81B5C8FC1B for ; Mon, 10 Mar 2008 13:40:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2ADe5kF005930 for ; Mon, 10 Mar 2008 13:40:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2ADe54p005929; Mon, 10 Mar 2008 13:40:05 GMT (envelope-from gnats) Date: Mon, 10 Mar 2008 13:40:05 GMT Message-Id: <200803101340.m2ADe54p005929@freefall.freebsd.org> To: freebsd-geom@FreeBSD.org From: Jaakko Heinonen Cc: Subject: Re: kern/121559: [patch] [geom] geom label class allows to create inaccessible labels X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jaakko Heinonen List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2008 13:40:05 -0000 The following reply was made to PR kern/121559; it has been noted by GNATS. From: Jaakko Heinonen To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/121559: [patch] [geom] geom label class allows to create inaccessible labels Date: Mon, 10 Mar 2008 15:35:56 +0200 --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline For some reason the report was truncated. Patch is attached to this mail and here is the complete "How-To-Repeat:"-section: (You need sysutils/e2fsprogs from ports.) # dd if=/dev/zero of=e2img bs=1M count=10 10+0 records in 10+0 records out 10485760 bytes transferred in 0.334605 secs (31337729 bytes/sec) # mdconfig -a -t vnode -f e2img md0 # mke2fs /dev/md0 . . # e2label /dev/md0 / # ls -ia /dev/ext2fs/ ls: : No such file or directory 120 . 2 .. # e2label /dev/md0 /foo # dmesg|tail -1 GEOM_LABEL: Label for provider md0 is ext2fs//foo. # ls -ia /dev/ext2fs/ ls: : No such file or directory # e2label /dev/md0 foo/ # dmesg|tail -1 GEOM_LABEL: Label for provider md0 is ext2fs/foo/. # ls -ia /dev/ext2fs/ ls: : No such file or directory 120 . 2 .. 122 foo # ls -ia /dev/ext2fs/foo/ ls: : No such file or directory 122 . 120 .. # glabel create /..bar/.. md0 # glabel status Name Status Components ext2fs/foo/ N/A md0 label//..bar/.. N/A md0 # ls -ia /dev/label/ ls: : No such file or directory 124 . 2 .. 125 foo # ls -ia /dev/label/foo/ 125 . 124 .. 126 ..bar.. # glabel create '' md0 After applying the patch: # dd if=/dev/zero of=e2img bs=1M count=10 # mdconfig -a -t vnode -f e2img md0 # mke2fs /dev/md0 . . # e2label /dev/md0 / # dmesg|tail -1 GEOM_LABEL: md0 contains suspicious label, skipping. # e2label /dev/md0 /foo # dmesg|tail -1 GEOM_LABEL: md0 contains suspicious label, skipping. # e2label /dev/md0 foo/ # dmesg|tail -1 GEOM_LABEL: md0 contains suspicious label, skipping. # glabel create /..bar/.. md0 glabel: Label name /..bar/.. is invalid. # glabel create '' md0 glabel: Label name is invalid. -- Jaakko --fdj2RfSjLxBAspz7 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="geom-label-allowed-names.diff" Index: label/g_label.c =================================================================== RCS file: /home/ncvs/src/sys/geom/label/g_label.c,v retrieving revision 1.21 diff -p -u -r1.21 g_label.c --- label/g_label.c 12 Aug 2006 15:30:24 -0000 1.21 +++ label/g_label.c 10 Mar 2008 10:34:26 -0000 @@ -122,14 +122,24 @@ g_label_is_name_ok(const char *label) { const char *s; - /* Check is the label starts from ../ */ + /* Don't allow empty labels */ + if (label[0] == '\0') + return (0); + /* Check if the label starts with '/' */ + if (label[0] == '/') + return (0); + /* Check if the label starts from ../ */ if (strncmp(label, "../", 3) == 0) return (0); - /* Check is the label contains /../ */ + /* Check if the label contains /../ */ if (strstr(label, "/../") != NULL) return (0); - /* Check is the label ends at ../ */ - if ((s = strstr(label, "/..")) != NULL && s[3] == '\0') + /* Check if the label ends at /.. */ + for (s = label; (s = strstr(s, "/..")) != NULL; s++) + if (s[3] == '\0') + return (0); + /* Check if the label ends with '/' */ + if ((s = rindex(label, '/')) != NULL && s[1] == '\0') return (0); return (1); } @@ -149,6 +159,8 @@ g_label_create(struct gctl_req *req, str G_LABEL_DEBUG(0, "%s contains suspicious label, skipping.", pp->name); G_LABEL_DEBUG(1, "%s suspicious label is: %s", pp->name, label); + if (req != NULL) + gctl_error(req, "Label name %s is invalid.", label); return (NULL); } gp = NULL; @@ -340,7 +352,7 @@ g_label_ctl_create(struct gctl_req *req, return; } if (*nargs != 2) { - gctl_error(req, "Invalid number of argument."); + gctl_error(req, "Invalid number of arguments."); return; } /* --fdj2RfSjLxBAspz7-- From owner-freebsd-geom@FreeBSD.ORG Thu Mar 13 00:12:34 2008 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC16C1065671 for ; Thu, 13 Mar 2008 00:12:34 +0000 (UTC) (envelope-from dwiest@vailsys.com) Received: from cprobd02.vailsys.com (cprobd02.vailsys.com [63.210.102.130]) by mx1.freebsd.org (Postfix) with ESMTP id 99F888FC14 for ; Thu, 13 Mar 2008 00:12:34 +0000 (UTC) (envelope-from dwiest@vailsys.com) Received: from dpfuser01.vail (dpfuser01.vail [192.168.129.103]) by cprobd02.vailsys.com (Postfix) with ESMTP id DBDBDCE667 for ; Wed, 12 Mar 2008 19:12:33 -0500 (CDT) Received: from dfwdamian.vail (dfwdamian.vail [192.168.129.233]) by dpfuser01.vail (Postfix) with ESMTP id D7BC25C5A for ; Wed, 12 Mar 2008 19:12:32 -0500 (CDT) Received: (from dwiest@localhost) by dfwdamian.vail (8.13.8/8.13.8/Submit) id m2D0CWGG089247 for freebsd-geom@freebsd.org; Wed, 12 Mar 2008 19:12:32 -0500 (CDT) (envelope-from dwiest@vailsys.com) X-Authentication-Warning: dfwdamian.vail: dwiest set sender to dwiest@vailsys.com using -f Date: Wed, 12 Mar 2008 19:12:32 -0500 From: Damian Wiest To: freebsd-geom@freebsd.org Message-ID: <20080313001232.GL32089@dfwdamian.vail> References: <20080307230058.GA8902@keira.kiwi-computer.com> <20080308024954.GF15859@dfwdamian.vail> <20080308064455.GA13341@keira.kiwi-computer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080308064455.GA13341@keira.kiwi-computer.com> User-Agent: Mutt/1.4.2.3i Subject: Re: geom_vinum platform-independent brokenness X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2008 00:12:34 -0000 On Sat, Mar 08, 2008 at 12:44:55AM -0600, Rick C. Petty wrote: > On Fri, Mar 07, 2008 at 08:49:54PM -0600, Damian Wiest wrote: > > > > So you're saying that you should be able to remove a disk (or set of disks) > > from an x86 system, install it in a system running the amd64 release and > > have things just work? > > That is the plan. At work, we have a couple of machines on which we wanted > to try amd64, but couldn't boot since the root fs is in gvinum. It makes > sense for people who want perhaps to dual boot or otherwise want to migrate > their data. > > > I would imagine that most people would simply use > > dump/restore, but I agree that it would be nice if one didn't have to do > > this. > > That solution obviously requires twice the disk space. It's especially > worse if you're using RAID5. At home I'm considering upgrading to amd64 > (since it's only a file server), but I don't have 4 TB of spare disks lying > around for the migration. > > > How is this scenario handled for basic disks? > > I'm not sure I understand your question. I was just thinking of the simplest case where the disk you're moving used a bsdlabel. > > Can an amd64 system > > handle a disk that was labeled on an x86 system? > > No, that was exactly the problem I am describing. It noticed that there > were vinum disks, but the configuration was all screwed up. > > > I haven't ever tried > > this, but the manpage for bsdlabel suggests that it won't work unless > > you originally wrote an amd64 label by using the -m option. > > I'm not talking about the disklabel here. geom_vinum takes up the first > 265 sectors (512 bytes each) to store its configuration. These are > straight-up disks that aren't needed in Windoze or other OS-- just plain > FreeBSD, so we use the full disks without labels or MBR partitions. Right. I was just wondering what would need to be changed when moving a bsdlabeled disk from x86 to amd64 or vice-versa. I was thinking that if the labels (both bsdlabel and gvinum's) were padded a bit at the end (so you don't clobber any real data), then one could simply rewrite the label once the disk was moved to the new system. My thinking was that it might be simpler to allow the label to be rewritten with some utility versus modifying how gvinum interprets labels. > > Aren't you going to run into issues with your filesystems when moving > > from one architecture to another that uses a different bus width? > > How so? Are you saying there are bugs in UFS which will prevent this from > working? If so, this is a much bigger problem than I anticipated. Looking > at sys/ufs/ffs/fs.h, I do see a bunch of pointers in the superblock > structure ("struct fs"), but all other superblock fields and other on-disk > structures have fixed size values. Also there's a sanity test on the size > of the "struct fs". Someone clearly has thought of this problem > (McKusick ?). After some minimal testing of mounting i386-created UFS2 > volumes on amd64, everything seems to work just fine. > > I've also investigated geom_mirror, and the on-disk structure seems clean. > There may be others that are broken, but geom_vinum is what I've noticed > and that is what I intend to fix. If UFS *is* broken, it should be fixed > also. > > Thank you for reminding me to test the filesystem! > > -- Rick C. Petty No, I wasn't saying anything about UFS in particular. Just that you'll also want to consider the underlying filesystems and not just the gvinum bits. -Damian From owner-freebsd-geom@FreeBSD.ORG Thu Mar 13 14:36:17 2008 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E18EA106567B for ; Thu, 13 Mar 2008 14:36:17 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from bene2.itea.ntnu.no (bene2.itea.ntnu.no [IPv6:2001:700:300:3::57]) by mx1.freebsd.org (Postfix) with ESMTP id D85198FC1F for ; Thu, 13 Mar 2008 14:36:16 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from localhost (localhost [127.0.0.1]) by bene2.itea.ntnu.no (Postfix) with ESMTP id BA98D161DFC; Thu, 13 Mar 2008 15:36:14 +0100 (CET) Received: from webmail.ntnu.no (textus11.itea.ntnu.no [129.241.56.161]) by bene2.itea.ntnu.no (Postfix) with ESMTP id BE891161DFE; Thu, 13 Mar 2008 15:35:51 +0100 (CET) Received: from u-211000159078.hotspot.ne.jp (u-211000159078.hotspot.ne.jp [211.0.159.78]) by webmail.ntnu.no (Horde MIME library) with HTTP; Thu, 13 Mar 2008 15:35:51 +0100 Message-ID: <20080313153551.82wlu8iio4088c44@webmail.ntnu.no> Date: Thu, 13 Mar 2008 15:35:51 +0100 From: lulf@stud.ntnu.no To: rick-freebsd@kiwi-computer.com References: <20080310052711.GA49676@keira.kiwi-computer.com> In-Reply-To: <20080310052711.GA49676@keira.kiwi-computer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.5) X-Virus-Scanned: Debian amavisd-new at bene2.itea.ntnu.no Cc: freebsd-geom@freebsd.org Subject: Re: [patch] geom_vinum platform fixes X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2008 14:36:18 -0000 Siterer "Rick C. Petty" : > Attached is a patch against RELENG_6 (but applies cleanly against > RELENG_7). It contains a fix to the geom_vinum platform brokenness > explained in my earlier email. Please review the patch and provide any > feedback. I will try to find a committer to review/commit this and any > subsequent changes early this week. Hello, I've spent a _lot_ of time fixing gvinum, so your previous statements =20 saying noone is fixing gvinum really is wrong :) I'm sorry this is taking so long, but there has been much time invested in 7.0 before gvinum. I'm also in Japan for another two weeks, so I won't be able to continue a discussion on this right now. But I agree with your changes, and I'll review and integrate your changes to the new code base ASAP, but this will probably not go in until the =20 new gvinum codebase iscommitted, since that will probably happen before 7.1/6.4 anywa= y -- Ulf Lilleengen > > Here is a quick overview of the patch. I've split the reading and writing > of the on-disk vinum header into separate functions. The header is read > by gv_drive_taste() and written by gv_save_config() and gv_rm_drive(). > > For reads, there are three possible on-disk formats it handles: the legac= y > i386 and legacy amd64 formats and the current (forward-going) format. The > legacy formats are distinguished by the algorithm in > gv_test_legacy_header_type(), which tests for known zeros, etc. Both > legacy formats are stored in little-endian, and this code should work on > all architectures regardless of endianness. I use a separate in-memory > structure to simplify the conversions. > > For writes, the patch only supports the new forward-going on-disk format. > This format is stored in big-endian (network order, also it's easier to > read with hexdump) and uses a new magic. This new magic value contains a > version number which I've started at 1, in case future enhancements are > made to the on-disk structure. Note that devices with old formats are > auto-upgraded when the configuration is written, which does not happen > unless "gvinum saveconfig" is used or the gvinum configuration is changed > for any reason. This lets admins keep using the old format. All new > devices added to gvinum will get the new format. > > I've tested this patch on 6.3-stable (i386) and 7.0-stable (i386, amd64) > systems, using vinum configurations created by amd64 & i386 formats and by > the new format. Other testers are welcome! > > -- Rick C. Petty > From owner-freebsd-geom@FreeBSD.ORG Thu Mar 13 18:00:33 2008 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AC531065670 for ; Thu, 13 Mar 2008 18:00:33 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (keira.kiwi-computer.com [63.224.10.3]) by mx1.freebsd.org (Postfix) with SMTP id BF6B48FC19 for ; Thu, 13 Mar 2008 18:00:32 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 15069 invoked by uid 2001); 13 Mar 2008 18:00:31 -0000 Date: Thu, 13 Mar 2008 12:00:31 -0600 From: "Rick C. Petty" To: Damian Wiest Message-ID: <20080313180031.GA14969@keira.kiwi-computer.com> References: <20080307230058.GA8902@keira.kiwi-computer.com> <20080308024954.GF15859@dfwdamian.vail> <20080308064455.GA13341@keira.kiwi-computer.com> <20080313001232.GL32089@dfwdamian.vail> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080313001232.GL32089@dfwdamian.vail> User-Agent: Mutt/1.4.2.3i Cc: freebsd-geom@freebsd.org Subject: Re: geom_vinum platform-independent brokenness X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2008 18:00:33 -0000 On Wed, Mar 12, 2008 at 07:12:32PM -0500, Damian Wiest wrote: > > I was just thinking of the simplest case where the disk you're moving > used a bsdlabel. Ok. > > I'm not talking about the disklabel here. geom_vinum takes up the first > > 265 sectors (512 bytes each) to store its configuration. These are > > straight-up disks that aren't needed in Windoze or other OS-- just plain > > FreeBSD, so we use the full disks without labels or MBR partitions. > > Right. I was just wondering what would need to be changed when moving > a bsdlabeled disk from x86 to amd64 or vice-versa. I was thinking that > if the labels (both bsdlabel and gvinum's) were padded a bit at the end > (so you don't clobber any real data), then one could simply rewrite the > label once the disk was moved to the new system. My thinking was that > it might be simpler to allow the label to be rewritten with some utility > versus modifying how gvinum interprets labels. geom_vinum has nothing to do with bsdlabels. There is extra padding at the beginning of the vinum configuration to allow for an MBR and/or a bsdlabel. Because gvinum uses GEOM's tasting, all providers are searched for vinum configuration.. It shouldn't matter whether you have a bsdlabel or not; geom_vinum just seeks to byte 4096 into each provider and checks for the magic. > No, I wasn't saying anything about UFS in particular. Just that you'll > also want to consider the underlying filesystems and not just the gvinum > bits. *My* concern is the gvinum bits. UFS seems to work for me, other file systems are beyond the scope of this personal project. -- Rick C. Petty From owner-freebsd-geom@FreeBSD.ORG Thu Mar 13 18:22:58 2008 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4753E106566C for ; Thu, 13 Mar 2008 18:22:58 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (keira.kiwi-computer.com [63.224.10.3]) by mx1.freebsd.org (Postfix) with SMTP id D81548FC1B for ; Thu, 13 Mar 2008 18:22:57 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 15443 invoked by uid 2001); 13 Mar 2008 18:22:57 -0000 Date: Thu, 13 Mar 2008 12:22:57 -0600 From: "Rick C. Petty" To: lulf@stud.ntnu.no Message-ID: <20080313182257.GB14969@keira.kiwi-computer.com> References: <20080310052711.GA49676@keira.kiwi-computer.com> <20080313153551.82wlu8iio4088c44@webmail.ntnu.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080313153551.82wlu8iio4088c44@webmail.ntnu.no> User-Agent: Mutt/1.4.2.3i Cc: freebsd-geom@freebsd.org Subject: Re: [patch] geom_vinum platform fixes X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2008 18:22:58 -0000 On Thu, Mar 13, 2008 at 03:35:51PM +0100, lulf@stud.ntnu.no wrote: > > I've spent a _lot_ of time fixing gvinum, so your previous statements > saying noone is fixing gvinum really is wrong :) Sorry, I didn't mean to be offensive or to downplay your work. I was referring to the fact that nothing vinum-related has been committed into geom_vinum in over 11 months. I am aware you were working on various fixes in p4, and I do appreciate your efforts. However, the particular areas I was interested in have been bugs since the introduction of plain vinum many years ago. I also didn't think your work addressed this particular issue. Since it has been a few weeks since 7.0 was tagged, I had assumed you were not going to continue working on this. > I'm sorry this is taking so > long, but there has been much time invested in 7.0 before gvinum. I'm > also in Japan for another two weeks, so I won't be able to continue a > discussion on this right now. > > But I agree with your changes, and I'll review and integrate your changes > to the new code base ASAP, but this will probably not go in until the > new gvinum > codebase iscommitted, since that will probably happen before 7.1/6.4 anyway I'm not sure I want to wait that long. My changes should not conflict with yours (and if they do, the overlap would be minimal). I don't see why the world should wait until 7.1 to see this fixed. Right now, people cannot migrate vinum partitions between i386 and amd64. These people don't need all your improvements for that. Besides, my small patch introduces little to no instability to geom_vinum and fixes a key piece of broken code. Compared to your larger commit, I would think people would prefer to see my patch committed immediately and your work to be integrated when you have time to test and commit it. That being said and since there have been no objections to my suggestions (and Ulf agrees with my changes), is a committer willing to review my patch? le@ ? Mr. Lehey? -- Rick C. Petty From owner-freebsd-geom@FreeBSD.ORG Sat Mar 15 08:23:21 2008 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3520D1065683 for ; Sat, 15 Mar 2008 08:23:21 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from bene1.itea.ntnu.no (bene1.itea.ntnu.no [IPv6:2001:700:300:3::56]) by mx1.freebsd.org (Postfix) with ESMTP id 22D128FC1B for ; Sat, 15 Mar 2008 08:23:18 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from localhost (localhost [127.0.0.1]) by bene1.itea.ntnu.no (Postfix) with ESMTP id 22B3416C6BE; Sat, 15 Mar 2008 09:23:17 +0100 (CET) Received: from webmail.ntnu.no (textus12.itea.ntnu.no [129.241.56.162]) by bene1.itea.ntnu.no (Postfix) with ESMTP id AB60516C1C4; Sat, 15 Mar 2008 09:23:10 +0100 (CET) Received: from FLA1Aai060.kng.mesh.ad.jp (FLA1Aai060.kng.mesh.ad.jp [61.193.102.60]) by webmail.ntnu.no (Horde MIME library) with HTTP; Sat, 15 Mar 2008 09:23:10 +0100 Message-ID: <20080315092310.g35m2dzkgcko4k8o@webmail.ntnu.no> Date: Sat, 15 Mar 2008 09:23:10 +0100 From: lulf@stud.ntnu.no To: rick-freebsd@kiwi-computer.com References: <20080310052711.GA49676@keira.kiwi-computer.com> <20080313153551.82wlu8iio4088c44@webmail.ntnu.no> <20080313182257.GB14969@keira.kiwi-computer.com> In-Reply-To: <20080313182257.GB14969@keira.kiwi-computer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.5) X-Virus-Scanned: Debian amavisd-new at bene1.itea.ntnu.no Cc: freebsd-geom@freebsd.org Subject: Re: [patch] geom_vinum platform fixes X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2008 08:23:21 -0000 Siterer "Rick C. Petty" : > On Thu, Mar 13, 2008 at 03:35:51PM +0100, lulf@stud.ntnu.no wrote: >> >> I've spent a _lot_ of time fixing gvinum, so your previous statements >> saying noone is fixing gvinum really is wrong :) > SNIP >> I'm sorry this is taking so >> long, but there has been much time invested in 7.0 before gvinum. I'm >> also in Japan for another two weeks, so I won't be able to continue a >> discussion on this right now. >> >> But I agree with your changes, and I'll review and integrate your change= s >> to the new code base ASAP, but this will probably not go in until the >> new gvinum >> codebase iscommitted, since that will probably happen before 7.1/6.4 any= way > > I'm not sure I want to wait that long. My changes should not conflict wit= h > yours (and if they do, the overlap would be minimal). I don't see why the > world should wait until 7.1 to see this fixed. Right now, people cannot > migrate vinum partitions between i386 and amd64. These people don't need > all your improvements for that. Besides, my small patch introduces little > to no instability to geom_vinum and fixes a key piece of broken code. > Compared to your larger commit, I would think people would prefer to see m= y > patch committed immediately and your work to be integrated when you have > time to test and commit it. > Hmm, yes. I didnt look very detailed at the patch so I was not sure if =20 it would conflict or not. > That being said and since there have been no objections to my suggestions > (and Ulf agrees with my changes), is a committer willing to review my > patch? le@ ? Mr. Lehey? > or lulf@ :) I can commit it after Ive reviewed it unless someone else volunteers =20 before Icome back from Japan (The 25th of march). > -- Rick C. Petty > > --=20 Ulf Lilleengen