From owner-freebsd-geom@FreeBSD.ORG Sun Jul 5 18:10:05 2009 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 66A8D1065687 for ; Sun, 5 Jul 2009 18:10: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 390818FC0A for ; Sun, 5 Jul 2009 18:10: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.3/8.14.3) with ESMTP id n65IA47W064092 for ; Sun, 5 Jul 2009 18:10:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n65IA4lD064091; Sun, 5 Jul 2009 18:10:04 GMT (envelope-from gnats) Date: Sun, 5 Jul 2009 18:10:04 GMT Message-Id: <200907051810.n65IA4lD064091@freefall.freebsd.org> To: freebsd-geom@FreeBSD.org From: =?ISO-8859-1?Q?Marius_N=FCnnerich?= Cc: Subject: Re: bin/128398: [patch] glabel(8): teach geom_label to recognise gpt labels and uuids X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?ISO-8859-1?Q?Marius_N=FCnnerich?= List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 18:10:05 -0000 The following reply was made to PR bin/128398; it has been noted by GNATS. From: =?ISO-8859-1?Q?Marius_N=FCnnerich?= To: bug-followup@FreeBSD.org Cc: Subject: Re: bin/128398: [patch] glabel(8): teach geom_label to recognise gpt labels and uuids Date: Sun, 5 Jul 2009 19:37:32 +0200 Thank Ivan, this PR can be closed now. From owner-freebsd-geom@FreeBSD.ORG Mon Jul 6 11:06:58 2009 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 95BE61065678 for ; Mon, 6 Jul 2009 11:06:58 +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 8117C8FC13 for ; Mon, 6 Jul 2009 11:06:58 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n66B6w5f010772 for ; Mon, 6 Jul 2009 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n66B6v6h010768 for freebsd-geom@FreeBSD.org; Mon, 6 Jul 2009 11:06:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 6 Jul 2009 11:06:57 GMT Message-Id: <200907061106.n66B6v6h010768@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, 06 Jul 2009 11:06:59 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/135898 geom [geom] Severe filesystem corruption - large files or l o kern/135874 geom [geom] [patch] geom_linux_lvm misses newer fedora defa o kern/134922 geom [gmirror] [panic] kernel panic when use fdisk on disk o kern/134113 geom [geli] Problem setting secondary GELI key o kern/134044 geom [geom] gmirror(8) overwrites fs with stale data from r o kern/133931 geom [geli] [request] intentionally wrong password to destr o bin/132845 geom [geom] [patch] ggated(8) does not close files opened a o kern/132273 geom glabel(8): [patch] failing on journaled partition o kern/132242 geom [gmirror] gmirror.ko fails to fully initialize o kern/131353 geom [geom] gjournal(8) kernel lock o kern/131037 geom [geli] Unable to create disklabel on .eli-Device p docs/130548 geom [patch] gjournal(8) man page is missing sysctls o kern/130528 geom gjournal fsck during boot o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid o bin/128398 geom [patch] glabel(8): teach geom_label to recognise gpt l f kern/128276 geom [gmirror] machine lock up when gmirror module is used o kern/126902 geom [geom] geom_label: kernel panic during install boot o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin o kern/124130 geom [gmirror] [usb] gmirror fails to start usb devices tha o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123630 geom [patch] [gmirror] gmirror doesnt allow the original dr o kern/123122 geom [geom] GEOM / gjournal kernel lock o kern/122738 geom [geom] gmirror list "losts consumers" after gmirror de f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/121481 geom [gmirror] data rot on disk with gmirror o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120231 geom [geom] GEOM_CONCAT error adding second drive o kern/120091 geom [geom] [geli] [gjournal] geli does not prompt for pass o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis o kern/120021 geom [geom] [panic] net-p2p/qbittorrent crashes system when o kern/119743 geom [geom] geom label for cds is keeped after dismount and p kern/116896 geom [geom] [patch] Typo in a kassert in GEOM o kern/115856 geom [geli] ZFS thought it was degraded when it should have o kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113885 geom [gmirror] [patch] improved gmirror balance algorithm o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o bin/90093 geom fdisk(8) incapable of altering in-core geometry a kern/89660 geom [vinum] [patch] [panic] due to g_malloc returning null o kern/89546 geom [geom] GEOM error s kern/89102 geom [geom] [panic] panic when forced unmount FS from unplu o kern/88601 geom [geli] geli cause kernel panic under heavy disk usage o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o bin/81779 geom misleading error messages in geom(8) utilities. o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o bin/78131 geom gbde(8) "destroy" not working. s kern/73177 geom kldload geom_* causes panic due to memory exhaustion 63 problems total. From owner-freebsd-geom@FreeBSD.ORG Mon Jul 6 11:32:47 2009 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 4B79E1065677 for ; Mon, 6 Jul 2009 11:32:47 +0000 (UTC) (envelope-from freeaz@gmail.com) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by mx1.freebsd.org (Postfix) with ESMTP id C662E8FC24 for ; Mon, 6 Jul 2009 11:32:46 +0000 (UTC) (envelope-from freeaz@gmail.com) Received: by bwz21 with SMTP id 21so318085bwz.43 for ; Mon, 06 Jul 2009 04:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:x-mailer:mime-version:content-type :content-transfer-encoding; bh=GE0T7gsB40BSaDz/VaFHRT7imqp17wPuuNTPdyWyR3o=; b=ESp+FWVEOKx3oMES4ESF1Ga9WZkahKmWuBfKwK0aheTs3t3DAfVmuFFQMmaIiludZm WGqfsFHENb6l3jaxD+fkCWtnXNkmAvuKXfQxbg/j3vY5Cy2Sq0ItHzbgbxy6vIA78MF1 BFk7+hQH/obLI02efh6RoxL4iaqdkpTxF7+YE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:x-mailer:mime-version:content-type :content-transfer-encoding; b=pZz/seAtn2HcFy6P6uYlMjJypJ8LWmOaXrhFvqvONK/lPL3ago4UzCsY7scoOZ54Nb DioPqJ9hX2iwNVjEDAQ/kJJSdxCjvIKoBbSvjdFBUi3Mu2Y+m6EJ6WaTkpMPMRDjt1P7 ICNaSF3CeBUuVK0mJnv3/Rj4fqC7ngPayOt9Q= Received: by 10.103.218.9 with SMTP id v9mr2558284muq.109.1246879237688; Mon, 06 Jul 2009 04:20:37 -0700 (PDT) Received: from az (113.37.broadband11.iol.cz [90.178.37.113]) by mx.google.com with ESMTPS id e9sm4321689muf.2.2009.07.06.04.20.36 (version=SSLv3 cipher=RC4-MD5); Mon, 06 Jul 2009 04:20:37 -0700 (PDT) Date: Mon, 6 Jul 2009 13:20:36 +0200 From: aZ To: freebsd-geom@freebsd.org Message-ID: <20090706132036.7ccfc623@az> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: problems using geli on top of gmirror 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, 06 Jul 2009 11:32:47 -0000 Hello, I have the same error. :( Bye. From owner-freebsd-geom@FreeBSD.ORG Tue Jul 7 11:02:23 2009 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 D092F1065673; Tue, 7 Jul 2009 11:02:23 +0000 (UTC) (envelope-from ivoras@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A5C2E8FC1A; Tue, 7 Jul 2009 11:02:23 +0000 (UTC) (envelope-from ivoras@FreeBSD.org) Received: from freefall.freebsd.org (ivoras@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n67B2NRp005917; Tue, 7 Jul 2009 11:02:23 GMT (envelope-from ivoras@freefall.freebsd.org) Received: (from ivoras@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n67B2N53005913; Tue, 7 Jul 2009 11:02:23 GMT (envelope-from ivoras) Date: Tue, 7 Jul 2009 11:02:23 GMT Message-Id: <200907071102.n67B2N53005913@freefall.freebsd.org> To: marius@nuenneri.ch, ivoras@FreeBSD.org, freebsd-geom@FreeBSD.org From: ivoras@FreeBSD.org Cc: Subject: Re: bin/128398: [patch] glabel(8): teach geom_label to recognise gpt labels and uuids 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: Tue, 07 Jul 2009 11:02:24 -0000 Synopsis: [patch] glabel(8): teach geom_label to recognise gpt labels and uuids State-Changed-From-To: open->closed State-Changed-By: ivoras State-Changed-When: Tue Jul 7 11:01:36 UTC 2009 State-Changed-Why: Patch applied. http://www.freebsd.org/cgi/query-pr.cgi?pr=128398 From owner-freebsd-geom@FreeBSD.ORG Tue Jul 7 11:07:08 2009 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 327811065672; Tue, 7 Jul 2009 11:07:08 +0000 (UTC) (envelope-from ivoras@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 07EDC8FC1A; Tue, 7 Jul 2009 11:07:08 +0000 (UTC) (envelope-from ivoras@FreeBSD.org) Received: from freefall.freebsd.org (ivoras@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n67B77rA006029; Tue, 7 Jul 2009 11:07:07 GMT (envelope-from ivoras@freefall.freebsd.org) Received: (from ivoras@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n67B77p2006025; Tue, 7 Jul 2009 11:07:07 GMT (envelope-from ivoras) Date: Tue, 7 Jul 2009 11:07:07 GMT Message-Id: <200907071107.n67B77p2006025@freefall.freebsd.org> To: zdbs@lif.de, ivoras@FreeBSD.org, freebsd-geom@FreeBSD.org From: ivoras@FreeBSD.org Cc: Subject: Re: kern/121481: [gmirror] data rot on disk with gmirror 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: Tue, 07 Jul 2009 11:07:08 -0000 Synopsis: [gmirror] data rot on disk with gmirror State-Changed-From-To: open->closed State-Changed-By: ivoras State-Changed-When: Tue Jul 7 11:05:46 UTC 2009 State-Changed-Why: Mostly irrelevant, RAID1 does not provide checksumming / data consistency checks that would catch bit-rot errors. (See ZFS for alternatives). http://www.freebsd.org/cgi/query-pr.cgi?pr=121481 From owner-freebsd-geom@FreeBSD.ORG Tue Jul 7 11:12:49 2009 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 532261065672; Tue, 7 Jul 2009 11:12:49 +0000 (UTC) (envelope-from ivoras@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 28B228FC17; Tue, 7 Jul 2009 11:12:49 +0000 (UTC) (envelope-from ivoras@FreeBSD.org) Received: from freefall.freebsd.org (ivoras@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n67BCnXE013008; Tue, 7 Jul 2009 11:12:49 GMT (envelope-from ivoras@freefall.freebsd.org) Received: (from ivoras@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n67BCmeX013004; Tue, 7 Jul 2009 11:12:48 GMT (envelope-from ivoras) Date: Tue, 7 Jul 2009 11:12:48 GMT Message-Id: <200907071112.n67BCmeX013004@freefall.freebsd.org> To: vanhu@netasq.com, ivoras@FreeBSD.org, freebsd-geom@FreeBSD.org From: ivoras@FreeBSD.org Cc: Subject: Re: kern/116896: [geom] [patch] Typo in a kassert in GEOM 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: Tue, 07 Jul 2009 11:12:49 -0000 Synopsis: [geom] [patch] Typo in a kassert in GEOM State-Changed-From-To: patched->closed State-Changed-By: ivoras State-Changed-When: Tue Jul 7 11:12:29 UTC 2009 State-Changed-Why: Patched and MFC-ed http://www.freebsd.org/cgi/query-pr.cgi?pr=116896 From owner-freebsd-geom@FreeBSD.ORG Tue Jul 7 11:14:08 2009 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 5FE9A1065673; Tue, 7 Jul 2009 11:14:08 +0000 (UTC) (envelope-from ivoras@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 36AAA8FC0A; Tue, 7 Jul 2009 11:14:08 +0000 (UTC) (envelope-from ivoras@FreeBSD.org) Received: from freefall.freebsd.org (ivoras@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n67BE8ON013874; Tue, 7 Jul 2009 11:14:08 GMT (envelope-from ivoras@freefall.freebsd.org) Received: (from ivoras@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n67BE7F4013857; Tue, 7 Jul 2009 11:14:07 GMT (envelope-from ivoras) Date: Tue, 7 Jul 2009 11:14:07 GMT Message-Id: <200907071114.n67BE7F4013857@freefall.freebsd.org> To: trasz@buziaczek.pl, ivoras@FreeBSD.org, freebsd-geom@FreeBSD.org From: ivoras@FreeBSD.org Cc: Subject: Re: bin/81779: misleading error messages in geom(8) utilities. 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: Tue, 07 Jul 2009 11:14:08 -0000 Synopsis: misleading error messages in geom(8) utilities. State-Changed-From-To: open->closed State-Changed-By: ivoras State-Changed-When: Tue Jul 7 11:13:54 UTC 2009 State-Changed-Why: Patched some time ago. http://www.freebsd.org/cgi/query-pr.cgi?pr=81779 From owner-freebsd-geom@FreeBSD.ORG Tue Jul 7 23:20:08 2009 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 D0A59106564A; Tue, 7 Jul 2009 23:20:08 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 69DDD8FC16; Tue, 7 Jul 2009 23:20:07 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by yxe11 with SMTP id 11so7466526yxe.3 for ; Tue, 07 Jul 2009 16:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=1wz2wTBtkFo56cVui6kpiS+Xn71x3ty+PrEHyXEP4Q0=; b=tQC22uBmsW58BO7Kh3AEAeIDIVmh2fCC8Og3MwtjN9hy3SKwNOouWz1wlsCQuaKhnF BG4a6eoZe8EbsfieteeZNYLL72n1/h1Pzsuv/I9WSpd162CiGprbKKlxWuP/Ivl9OVGM g+UKi/69SFLJ171lwUuGmT0zdtHCT7mSSQwuo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Y7myFZQOuzuvvK8vkK8jgbAdLTgK+HnOVMg0YXse9BkBbM/mWBYTZ9DXHtmt6apWPw tZqIki7BNn5oxCoK0R1D/ewek5M5xEAQ65p0nrF82azMIOt60b7ToVAvkLQz3s+Fw/XD bH9n+pxSYfO9YQHwAn2R+VMEWrftX4ElHQnWE= MIME-Version: 1.0 Received: by 10.100.195.15 with SMTP id s15mr11494872anf.18.1247008807465; Tue, 07 Jul 2009 16:20:07 -0700 (PDT) Date: Wed, 8 Jul 2009 02:20:07 +0300 Message-ID: From: Dan Naumov To: Brooks Davis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, Freddie Cash , freebsd-geom@freebsd.org Subject: glabel metadata protection (WAS: ZFS: drive replacement performance) 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: Tue, 07 Jul 2009 23:20:09 -0000 >> Not to derail this discussion, but can anyone explain if the actual >> glabel metadata is protected in any way? If I use glabel to label a >> disk and then create a pool using /dev/label/disklabel, won't ZFS >> eventually overwrite the glabel metadata in the last sector since the >> disk in it's entirety is given to the pool? Or is every filesystem >> used by FreeBSD (ufs, zfs, etc) hardcoded to ignore the last few >> sectors of any disk and/or partition and not write data to it to avoid >> such issues? > > Disks labeled with glabel lose their last sector to the label. =A0It is n= ot > accessible by ZFS. =A0Disks with bsdlabel partition tables are at risk du= e to > the brain dead decision to allow partitions to overlap the first sector, > but modern designs like glabel avoid this mistake. > > -- Brooks So what happens if I was to do the following (for the same of example): gpart create -s GPT /dev/ad1 glabel label -v disk01 /dev/ad1 gpart add -b 1 -s -t freebsd-zfs /dev/ad1 Does "gpart add" automatically somehow recognize that the last sector of contains the glabel and automatically re-adjusts this command to make the freebsd-zfs partition take "entiredisk minus last sector" ? I can understand the logic of metadata being protected if I do a: "gpart add -b 1 -s -t freebsd-zfs /dev/label/disk01" since gpart will have to go through the actual label first, but what actually happens if I issue a gpart directly to the /dev/device? - Sincerely, Dan Naumov From owner-freebsd-geom@FreeBSD.ORG Wed Jul 8 01:07:16 2009 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 A0407106564A; Wed, 8 Jul 2009 01:07:16 +0000 (UTC) (envelope-from bp@barryp.org) Received: from itasca.hexavalent.net (itasca.hexavalent.net [67.207.138.180]) by mx1.freebsd.org (Postfix) with ESMTP id 68C618FC0A; Wed, 8 Jul 2009 01:07:16 +0000 (UTC) (envelope-from bp@barryp.org) Received: from eden.barryp.org (host-145-114-107-208.midco.net [208.107.114.145]) by itasca.hexavalent.net (Postfix) with ESMTPS id C57B223C549; Tue, 7 Jul 2009 19:49:52 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=barryp.org; s=itasca; t=1247014192; bh=vqsypQSX/+1KSkQr+XN249Yxr9LIFW9LP6e3Giijunk=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=LOVzwbeVl1WD tlp+cs9ugo1j5WY6K0dASg7rUlWOFfIvfhgflaUC7U2+5vOU5TodNNX7an9ghl/OEV1 7gn25z0tpmXzAahpTnGvcoF7v+gou3qDelivao00KY0B5KGZVTt9cqjbdSPAqr5QcRL jjgtZn7cfwDhriuyIBn7DFv9Q= Received: from [10.66.1.233] (helo=barry-pedersons-macbook.local) by eden.barryp.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1MOLM6-0003Sm-He; Tue, 07 Jul 2009 19:49:50 -0500 Message-ID: <4A53ED2D.4070309@barryp.org> Date: Tue, 07 Jul 2009 19:49:49 -0500 From: Barry Pederson User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Dan Naumov References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, freebsd-geom@freebsd.org Subject: Re: glabel metadata protection (WAS: ZFS: drive replacement performance) 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: Wed, 08 Jul 2009 01:07:17 -0000 Dan Naumov wrote: >>> If I use glabel to label a >>> disk and then create a pool using /dev/label/disklabel, won't ZFS >>> eventually overwrite the glabel metadata in the last sector since the >>> disk in it's entirety is given to the pool? I would say in this case you're *not* giving the entire disk to the pool, you're giving ZFS a geom that's one sector smaller than the disk. ZFS never sees or can touch the glabel metadata. > So what happens if I was to do the following (for the same of example): > > gpart create -s GPT /dev/ad1 > glabel label -v disk01 /dev/ad1 > gpart add -b 1 -s -t freebsd-zfs /dev/ad1 > > Does "gpart add" automatically somehow recognize that the last sector > of contains the glabel and automatically re-adjusts this > command to make the freebsd-zfs partition take "entiredisk minus last > sector" ? I can understand the logic of metadata being protected if I > do a: "gpart add -b 1 -s -t freebsd-zfs > /dev/label/disk01" since gpart will have to go through the actual > label first, but what actually happens if I issue a gpart directly to > the /dev/device? I'd guess bad stuff would happen here, with a conflict between what gpt and glabel would want to do with the end of the disk. If you wanted to use glabel with a GPT partition, I'd think you'd want to gpart create -s GPT /dev/ad1 (use "gpart show" to see what space is now available for GPT partitions, it won't start at 1 and won't go to the very end of the disk) gpart add -b 34 -s -t freebsd-zfs /dev/ad1 glabel label -v disk01 /dev/ad1p1 (and then use label/disk01 in a zpool) Barry From owner-freebsd-geom@FreeBSD.ORG Wed Jul 8 08:38:05 2009 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 782791065670; Wed, 8 Jul 2009 08:38:05 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 3EE698FC21; Wed, 8 Jul 2009 08:38:05 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOSfB-000BsX-HJ; Wed, 08 Jul 2009 09:38:01 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MOSfB-0004Rl-GS; Wed, 08 Jul 2009 09:38:01 +0100 To: bp@barryp.org, dan.naumov@gmail.com In-Reply-To: <4A53ED2D.4070309@barryp.org> Message-Id: From: Pete French Date: Wed, 08 Jul 2009 09:38:01 +0100 Cc: freebsd-stable@freebsd.org, freebsd-geom@freebsd.org Subject: Re: glabel metadata protection (WAS: ZFS: drive replacement performance) 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: Wed, 08 Jul 2009 08:38:05 -0000 > I would say in this case you're *not* giving the entire disk to the > pool, you're giving ZFS a geom that's one sector smaller than the disk. > ZFS never sees or can touch the glabel metadata. Is ZFS happy if the size of it's disc changes underneath it ? I have expanded a zpool a couple of times simply by changing the size of the partition and rebooting the machine - it comes up with the new amount of free space fine. Never tried it the other way though. The reason I mention it is that someone suggested glabeling a drive in an existing pool and using replace to swap it over. Which should be good I guess unless the last sector was in use. ZFS spreads stuff all over the disc as I unserdtand it though, so that might not be a good assumption, even on a fairly empty filesystem. -pete. From owner-freebsd-geom@FreeBSD.ORG Wed Jul 8 12:28:25 2009 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 2E2CF1065673; Wed, 8 Jul 2009 12:28:25 +0000 (UTC) (envelope-from trasz@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 03E8A8FC15; Wed, 8 Jul 2009 12:28:25 +0000 (UTC) (envelope-from trasz@FreeBSD.org) Received: from freefall.freebsd.org (trasz@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n68CSOUI020667; Wed, 8 Jul 2009 12:28:24 GMT (envelope-from trasz@freefall.freebsd.org) Received: (from trasz@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n68CSOnI020663; Wed, 8 Jul 2009 12:28:24 GMT (envelope-from trasz) Date: Wed, 8 Jul 2009 12:28:24 GMT Message-Id: <200907081228.n68CSOnI020663@freefall.freebsd.org> To: trasz@FreeBSD.org, freebsd-geom@FreeBSD.org, trasz@FreeBSD.org From: trasz@FreeBSD.org Cc: Subject: Re: kern/89102: [geom] [panic] panic when forced unmount FS from unplugged device 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: Wed, 08 Jul 2009 12:28:25 -0000 Synopsis: [geom] [panic] panic when forced unmount FS from unplugged device Responsible-Changed-From-To: freebsd-geom->trasz Responsible-Changed-By: trasz Responsible-Changed-When: Wed Jul 8 12:28:24 UTC 2009 Responsible-Changed-Why: I'll take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=89102 From owner-freebsd-geom@FreeBSD.ORG Wed Jul 8 18:58:13 2009 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 EF6371065670; Wed, 8 Jul 2009 18:58:13 +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 C5C9E8FC20; Wed, 8 Jul 2009 18:58:13 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n68IwDfO091112; Wed, 8 Jul 2009 18:58:13 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n68IwD8R091108; Wed, 8 Jul 2009 18:58:13 GMT (envelope-from linimon) Date: Wed, 8 Jul 2009 18:58:13 GMT Message-Id: <200907081858.n68IwD8R091108@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-geom@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/136467: [geom] glabel(8) destroys access to GEOM tree if volume label contains non ASCII characters 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: Wed, 08 Jul 2009 18:58:14 -0000 Old Synopsis: glabel destroys access to GEOM tree if volume label contains non ASCII characters New Synopsis: [geom] glabel(8) destroys access to GEOM tree if volume label contains non ASCII characters Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 8 18:57:58 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=136467 From owner-freebsd-geom@FreeBSD.ORG Wed Jul 8 20:20:23 2009 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 4ED79106567C for ; Wed, 8 Jul 2009 20:20:23 +0000 (UTC) (envelope-from freebsd-geom@hub.freebsd.org) Received: from athedsl-23882.home.otenet.gr (athedsl-18736.home.otenet.gr [87.202.73.194]) by mx1.freebsd.org (Postfix) with ESMTP id 3FFC88FC19 for ; Wed, 8 Jul 2009 20:20:22 +0000 (UTC) (envelope-from freebsd-geom@hub.freebsd.org) Message-ID: <6900VT.479913D19.0372788654NZMPOSSBRRDJXVS704@athedsl-23882.home.otenet.gr> Date: Wed, 8 Jul 2009 23:20:23 +0300 From: "Duncan Djhyof" To: freebsd-geom@hub.freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Review of your results 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: Wed, 08 Jul 2009 20:20:23 -0000 [1]Click here in case if image is blocked Today is Wednesday, July 8 [2]Check today's assignment. More on Love & Relationships [3]7 manual sex secrets [4]7 outrageous sex positions _________________________________________________________________ [5]Manage Your Subscriptions You are subscribed as freebsd-geom@hub.freebsd.org. To unsubscribe from this newsletter, please [6]click here [7]Privacy Policy | [8]Email Help | [9]About us References 1. http://dvtk02.vzeyihap.cn/?odexohykjn=1db6b13d19006c4ceea&oazebeiryfoj=18747028150 2. http://omqn45.vzeyihap.cn/?fuputj=1db6b13d19006c4ceea&talouaxql=18747028150 3. http://juh88.vzeyihap.cn/?qkyzqowjtibu=1db6b13d19006c4ceea&oxojhqcuol=18747028150 4. http://juh88.vzeyihap.cn/?yukofeq=1db6b13d19006c4ceea&yrebicoqtot=18747028150 5. http://juh88.vzeyihap.cn/?etudavivan=1db6b13d19006c4ceea&qtytooihosq=18747028150 6. http://juh88.vzeyihap.cn/?onyneexegoz=1db6b13d19006c4ceea&egarqlqys=18747028150 7. http://juh88.vzeyihap.cn/?hiegoljk=1db6b13d19006c4ceea&vibivym=18747028150 8. http://juh88.vzeyihap.cn/?ivoxet=1db6b13d19006c4ceea&ebqnefizix=18747028150 9. http://juh88.vzeyihap.cn/?ejryhqzan=1db6b13d19006c4ceea&jdakuvac=18747028150 From owner-freebsd-geom@FreeBSD.ORG Thu Jul 9 11:53:09 2009 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 187281065676 for ; Thu, 9 Jul 2009 11:53:09 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id CB0DE8FC23 for ; Thu, 9 Jul 2009 11:53:08 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MOsBV-000374-1e for freebsd-geom@freebsd.org; Thu, 09 Jul 2009 11:53:05 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Jul 2009 11:53:05 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Jul 2009 11:53:05 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Thu, 09 Jul 2009 13:52:53 +0200 Lines: 42 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.21 (X11/20090615) Sender: news Subject: glabel and real disk IDs 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, 09 Jul 2009 11:53:09 -0000 Hi, I've been working with glabels for a time and just remembered that ATA (ad) drives do in fact export the drive ID, for example: # diskinfo -v ad4 ad4 512 # sectorsize 320072933376 # mediasize in bytes (298G) 625142448 # mediasize in sectors 620181 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. ad:9QF4H15Y # Disk ident. # diskinfo -v ad6 ad6 512 # sectorsize 320072933376 # mediasize in bytes (298G) 625142448 # mediasize in sectors 620181 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. ad:9QF4EP7A # Disk ident. # diskinfo -v ad8 ad8 512 # sectorsize 320072933376 # mediasize in bytes (298G) 625142448 # mediasize in sectors 620181 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. ad:9QF4H16L # Disk ident. I don't think it would be hard to add a label parser to gather this information and export it as a label. The purpose of this would be to have a unique disk ID without explicitly setting a label (e.g. as is commonly advised for ZFS and drive swapping). Any objections? From owner-freebsd-geom@FreeBSD.ORG Thu Jul 9 13:33:59 2009 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 034EA1065676 for ; Thu, 9 Jul 2009 13:33:59 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id 99F018FC15 for ; Thu, 9 Jul 2009 13:33:58 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: by fxm24 with SMTP id 24so143246fxm.43 for ; Thu, 09 Jul 2009 06:33:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.174.18 with SMTP id b18mr405098mup.129.1247144730553; Thu, 09 Jul 2009 06:05:30 -0700 (PDT) In-Reply-To: References: Date: Thu, 9 Jul 2009 15:05:30 +0200 Message-ID: From: =?ISO-8859-1?Q?Marius_N=FCnnerich?= To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-geom@freebsd.org Subject: Re: glabel and real disk IDs 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, 09 Jul 2009 13:33:59 -0000 On Thu, Jul 9, 2009 at 13:52, Ivan Voras wrote: > Hi, > > I've been working with glabels for a time and just remembered that ATA (a= d) > drives do in fact export the drive ID, for example: > > # diskinfo -v ad4 > ad4 > =A0 =A0 =A0 =A0512 =A0 =A0 =A0 =A0 =A0 =A0 # sectorsize > =A0 =A0 =A0 =A0320072933376 =A0 =A0# mediasize in bytes (298G) > =A0 =A0 =A0 =A0625142448 =A0 =A0 =A0 # mediasize in sectors > =A0 =A0 =A0 =A0620181 =A0 =A0 =A0 =A0 =A0# Cylinders according to firmwar= e. > =A0 =A0 =A0 =A016 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Heads according to firmwar= e. > =A0 =A0 =A0 =A063 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Sectors according to firmw= are. > =A0 =A0 =A0 =A0ad:9QF4H15Y =A0 =A0 # Disk ident. > > # diskinfo -v ad6 > ad6 > =A0 =A0 =A0 =A0512 =A0 =A0 =A0 =A0 =A0 =A0 # sectorsize > =A0 =A0 =A0 =A0320072933376 =A0 =A0# mediasize in bytes (298G) > =A0 =A0 =A0 =A0625142448 =A0 =A0 =A0 # mediasize in sectors > =A0 =A0 =A0 =A0620181 =A0 =A0 =A0 =A0 =A0# Cylinders according to firmwar= e. > =A0 =A0 =A0 =A016 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Heads according to firmwar= e. > =A0 =A0 =A0 =A063 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Sectors according to firmw= are. > =A0 =A0 =A0 =A0ad:9QF4EP7A =A0 =A0 # Disk ident. > > # diskinfo -v ad8 > ad8 > =A0 =A0 =A0 =A0512 =A0 =A0 =A0 =A0 =A0 =A0 # sectorsize > =A0 =A0 =A0 =A0320072933376 =A0 =A0# mediasize in bytes (298G) > =A0 =A0 =A0 =A0625142448 =A0 =A0 =A0 # mediasize in sectors > =A0 =A0 =A0 =A0620181 =A0 =A0 =A0 =A0 =A0# Cylinders according to firmwar= e. > =A0 =A0 =A0 =A016 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Heads according to firmwar= e. > =A0 =A0 =A0 =A063 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Sectors according to firmw= are. > =A0 =A0 =A0 =A0ad:9QF4H16L =A0 =A0 # Disk ident. > > I don't think it would be hard to add a label parser to gather this > information and export it as a label. > > The purpose of this would be to have a unique disk ID without explicitly > setting a label (e.g. as is commonly advised for ZFS and drive swapping). > > Any objections? I like the idea. If one should use it in which situation is something diffe= rent. From owner-freebsd-geom@FreeBSD.ORG Thu Jul 9 14:01:49 2009 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 EF15E106568C; Thu, 9 Jul 2009 14:01:49 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E329D8FC17; Thu, 9 Jul 2009 14:01:48 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA10401; Thu, 09 Jul 2009 16:51:33 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A55F5E5.9080703@icyb.net.ua> Date: Thu, 09 Jul 2009 16:51:33 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090630) MIME-Version: 1.0 To: Ivan Voras References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org Subject: Re: glabel and real disk IDs 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, 09 Jul 2009 14:01:50 -0000 on 09/07/2009 14:52 Ivan Voras said the following: > Hi, > > I've been working with glabels for a time and just remembered that ATA > (ad) drives do in fact export the drive ID, for example: [snip] > I don't think it would be hard to add a label parser to gather this > information and export it as a label. > > The purpose of this would be to have a unique disk ID without explicitly > setting a label (e.g. as is commonly advised for ZFS and drive swapping). > > Any objections? This is a very good idea in my opinion. -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Thu Jul 9 19:40:02 2009 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 C7ED2106566C for ; Thu, 9 Jul 2009 19:40:02 +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 9A4528FC21 for ; Thu, 9 Jul 2009 19:40:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n69Je2WS046089 for ; Thu, 9 Jul 2009 19:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n69Je2aG046088; Thu, 9 Jul 2009 19:40:02 GMT (envelope-from gnats) Date: Thu, 9 Jul 2009 19:40:02 GMT Message-Id: <200907091940.n69Je2aG046088@freefall.freebsd.org> To: freebsd-geom@FreeBSD.org From: Ivan Voras Cc: Subject: Re: kern/136467: [geom] glabel(8) destroys access to GEOM tree if volume label contains non ASCII characters X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ivan Voras List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 19:40:03 -0000 The following reply was made to PR kern/136467; it has been noted by GNATS. From: Ivan Voras To: bug-followup@freebsd.org, IZ-FreeBSD0902@hs-karlsruhe.de Cc: Subject: Re: kern/136467: [geom] glabel(8) destroys access to GEOM tree if volume label contains non ASCII characters Date: Thu, 09 Jul 2009 13:48:35 +0200 Would you be happy with a sysctl knob that controls whether to interpret all labels as UTF-8 or to strip out all 8-bit characters, which would by default be set to "interpret as UTF-8"? From owner-freebsd-geom@FreeBSD.ORG Thu Jul 9 20:00:57 2009 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 EFCD0106566C for ; Thu, 9 Jul 2009 20:00:57 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206192061.chello.pl [87.206.192.61]) by mx1.freebsd.org (Postfix) with ESMTP id 48AC38FC16 for ; Thu, 9 Jul 2009 20:00:56 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id F018845C89; Thu, 9 Jul 2009 22:00:54 +0200 (CEST) Received: from localhost (chello087206192061.chello.pl [87.206.192.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id A83BD45683; Thu, 9 Jul 2009 22:00:49 +0200 (CEST) Date: Thu, 9 Jul 2009 22:01:02 +0200 From: Pawel Jakub Dawidek To: Ivan Voras Message-ID: <20090709200102.GA2438@garage.freebsd.pl> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-geom@freebsd.org Subject: Re: glabel and real disk IDs 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, 09 Jul 2009 20:00:58 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 09, 2009 at 01:52:53PM +0200, Ivan Voras wrote: > Hi, >=20 > I've been working with glabels for a time [...] You should stop, really. We have enough labels in /dev/ as it is. > [...] and just remembered that ATA=20 > (ad) drives do in fact export the drive ID, for example: >=20 > # diskinfo -v ad4 > ad4 > 512 # sectorsize > 320072933376 # mediasize in bytes (298G) > 625142448 # mediasize in sectors > 620181 # Cylinders according to firmware. > 16 # Heads according to firmware. > 63 # Sectors according to firmware. > ad:9QF4H15Y # Disk ident. >=20 > # diskinfo -v ad6 > ad6 > 512 # sectorsize > 320072933376 # mediasize in bytes (298G) > 625142448 # mediasize in sectors > 620181 # Cylinders according to firmware. > 16 # Heads according to firmware. > 63 # Sectors according to firmware. > ad:9QF4EP7A # Disk ident. >=20 > # diskinfo -v ad8 > ad8 > 512 # sectorsize > 320072933376 # mediasize in bytes (298G) > 625142448 # mediasize in sectors > 620181 # Cylinders according to firmware. > 16 # Heads according to firmware. > 63 # Sectors according to firmware. > ad:9QF4H16L # Disk ident. >=20 > I don't think it would be hard to add a label parser to gather this=20 > information and export it as a label. It was proposed in the past and the consensus was not to do it. One of the reasons was polution of /dev/, another one was that the way of getting SCSI disks IDs was not perfect. > The purpose of this would be to have a unique disk ID without explicitly= =20 > setting a label (e.g. as is commonly advised for ZFS and drive swapping). I guess you advice that? There is no such need when it comes to ZFS. ZFS can find his components just fine without using their names. Disk IDs were added for ZFS in the past, but now they serve no purpose, I'd prefer to remove them altogether or just leave them for informational purpose as they exist now. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --gBBFr7Ir9EOA20Yy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFKVkx+ForvXbEpPzQRAl8gAKCZFUl3Zr9k9pOs6DqLOhuuc3mecQCfZ+7u bRpziQP+8YJpIdiCF/98Jd0= =di1Y -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy-- From owner-freebsd-geom@FreeBSD.ORG Thu Jul 9 21:33:01 2009 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 6C0E6106564A; Thu, 9 Jul 2009 21:33:00 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id D1E058FC14; Thu, 9 Jul 2009 21:33:00 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp026.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KMJ00I55AIZ4B00@asmtp026.mac.com>; Thu, 09 Jul 2009 14:33:00 -0700 (PDT) From: Marcel Moolenaar In-reply-to: <20090709200102.GA2438@garage.freebsd.pl> Date: Thu, 09 Jul 2009 14:32:59 -0700 Message-id: References: <20090709200102.GA2438@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1068) Cc: Ivan Voras , freebsd-geom@freebsd.org Subject: Re: glabel and real disk IDs 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, 09 Jul 2009 21:33:01 -0000 On Jul 9, 2009, at 1:01 PM, Pawel Jakub Dawidek wrote: > >> The purpose of this would be to have a unique disk ID without >> explicitly >> setting a label (e.g. as is commonly advised for ZFS and drive >> swapping). > > I guess you advice that? There is no such need when it comes to ZFS. > ZFS > can find his components just fine without using their names. Disk IDs > were added for ZFS in the past, but now they serve no purpose, I'd > prefer to remove them altogether or just leave them for informational > purpose as they exist now. Just as an FYI: I see ZFS getting confused when disks are shuffled around. The confusion is the result of having device paths stored in the ZFS label match the device name of some other vdev that part of the same pool. Replacing a device with itself doesn't help, because ZFS complains that the vdev is part of an active pool in that case. It seems that only labels will work here... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-geom@FreeBSD.ORG Thu Jul 9 21:34:05 2009 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 D30F4106564A; Thu, 9 Jul 2009 21:34:05 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id EF4AC8FC1B; Thu, 9 Jul 2009 21:34:04 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by ey-out-2122.google.com with SMTP id 9so126380eyd.3 for ; Thu, 09 Jul 2009 14:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=ZmbNEZSHujweu2oHvgVISM2GxxzT+PgxDKtIB9EMNkg=; b=fzv/okr3n4ubzjU4p02peAxbwuKDBQhMFoqfYRjOndf42WaXcUJ/O7Nv+cnoEBC2pY k0eZwlSPf0lbwhOOXoQLsUWwV/Gs2ahO0z2CfU3l6Ivaal3PEtmPT5EAQfvXJ9fQ8geC fUTwXD9zjGk3rSkekzXoeLiMu6TDSNBq6JQMk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=hUXHeALoJ4OZ25H1CiBHED9yzs4zEZjWFgs2g4qrse9tVH20NlDjtS/Whls4Qbuqun mx342dP9Nc6y7AKes0Rq10AZ5bWm+Q2pUgfLMnktjs+8fvmv8OZeaVPAvNTzynRaitx7 QpViABvnXfdWNtPDFQ+g3GOn03T4Xsurd8a+0= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.210.114.15 with SMTP id m15mr1552381ebc.9.1247175244094; Thu, 09 Jul 2009 14:34:04 -0700 (PDT) In-Reply-To: <20090709200102.GA2438@garage.freebsd.pl> References: <20090709200102.GA2438@garage.freebsd.pl> From: Ivan Voras Date: Thu, 9 Jul 2009 23:33:44 +0200 X-Google-Sender-Auth: 3ea0d28d496d69d1 Message-ID: <9bbcef730907091433i6417de15o1462750b90fe54a@mail.gmail.com> To: Pawel Jakub Dawidek Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org Subject: Re: glabel and real disk IDs 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, 09 Jul 2009 21:34:06 -0000 I really am not doing the things I do to agitate you personally. We can debate on technical grounds and I will back down if sufficient technical or logical reasons are given. I will not reply to any part of your messages that seem too emotional. 2009/7/9 Pawel Jakub Dawidek : > One of the reasons was polution of /dev/, The pollution of the /dev namespace could have been lessened by using a different policy in naming devices, as was suggested before (by me and others). The situation now is that we have passed the point of no return when glabel as-is arrived in the GENERIC kernel. Putting a freeze on adding new label parsers to glabel will not change anything for the better and will not fix existing problems. > another one was that the way > of getting SCSI disks IDs was not perfect. On the other hand, ATA IDs seem ok. If there are problems I don't see with them, I'd like to find out about them, better sooner than later. >> The purpose of this would be to have a unique disk ID without explicitly >> setting a label (e.g. as is commonly advised for ZFS and drive swapping). > > I guess you advice that? There is no such need when it comes to ZFS. ZFS I am not involved in ZFS development enough to advise or disadvise anything, except that I notice that there apparently is a problem somewhere in that area and that using glabel to fixate disk names is a common advice given to those who encounter it. The most recent thread (and the direct cause of my post) is http://permalink.gmane.org/gmane.os.freebsd.stable/63970 . I remember there are other similar threads. > can find his components just fine without using their names. Disk IDs > were added for ZFS in the past, but now they serve no purpose, I'd > prefer to remove them altogether or just leave them for informational > purpose as they exist now. I have seen your commit and was surprised by it. Doesn't it mean that because of it ZFS will not automatically pick up renumbered/renamed drives? Was the reason of removing disk id usage from ZFS that it didn't work? Can you suggest a solution (or a better solution than manually labeling drives) to the "drives renumbered" problem in the above thread? Finally, I will do what I proposed except if a) there is a noticeable community or developer outcry not to do it, for whatever reason or b) strong technical reasons are presented from anyone that would make the proposal invalid, unsecure, problematic to maintain, problematic to use for general users or others. Please also note that glabel is optional and noone is forcing anyone to use it. If you have problems with others' modifications to glabel, I also respectfully propose to take maintainance of it. From owner-freebsd-geom@FreeBSD.ORG Thu Jul 9 22:24:14 2009 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 7B9A81065670 for ; Thu, 9 Jul 2009 22:24:14 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206192061.chello.pl [87.206.192.61]) by mx1.freebsd.org (Postfix) with ESMTP id B8A428FC14 for ; Thu, 9 Jul 2009 22:24:13 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 1459B45C89; Fri, 10 Jul 2009 00:24:12 +0200 (CEST) Received: from localhost (chello087206192061.chello.pl [87.206.192.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 031EF4569A; Fri, 10 Jul 2009 00:24:06 +0200 (CEST) Date: Fri, 10 Jul 2009 00:24:20 +0200 From: Pawel Jakub Dawidek To: Marcel Moolenaar Message-ID: <20090709222420.GE2438@garage.freebsd.pl> References: <20090709200102.GA2438@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8vCeF2GUdMpe9ZbK" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-geom@freebsd.org Subject: Re: glabel and real disk IDs 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, 09 Jul 2009 22:24:14 -0000 --8vCeF2GUdMpe9ZbK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 09, 2009 at 02:32:59PM -0700, Marcel Moolenaar wrote: >=20 > On Jul 9, 2009, at 1:01 PM, Pawel Jakub Dawidek wrote: >=20 > > > >>The purpose of this would be to have a unique disk ID without =20 > >>explicitly > >>setting a label (e.g. as is commonly advised for ZFS and drive =20 > >>swapping). > > > >I guess you advice that? There is no such need when it comes to ZFS. =20 > >ZFS > >can find his components just fine without using their names. Disk IDs > >were added for ZFS in the past, but now they serve no purpose, I'd > >prefer to remove them altogether or just leave them for informational > >purpose as they exist now. >=20 > Just as an FYI: >=20 > I see ZFS getting confused when disks are shuffled around. > The confusion is the result of having device paths stored > in the ZFS label match the device name of some other vdev > that part of the same pool. >=20 > Replacing a device with itself doesn't help, because ZFS > complains that the vdev is part of an active pool in that > case. It seems that only labels will work here... Solaris is using device names stored in ZFS label and if this is not the drive it was looking for, it is doing ID-to-path translation to find new path name. On FreeBSD on the other hand (after upgrade to v13) I gave up doing similar thing because disk IDs weren't available from all disk device drivers (I implemented it for ATA and I received no help with other drivers). Currently the idea is to just go through all GEOM providers looking for proper ZFS metadata (think of it as manual tasting), so even if device name changes, ZFS should be able to locate it. If there are still problems locating the disk, there simply might be a bug in the code of some sort. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --8vCeF2GUdMpe9ZbK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFKVm4UForvXbEpPzQRAgp1AJ4i4vO8MFGJoJjFAFlMFfdx+C1sAQCfdjmV ItDVphnCZaHfRLTpq8UMxTo= =N+uU -----END PGP SIGNATURE----- --8vCeF2GUdMpe9ZbK-- From owner-freebsd-geom@FreeBSD.ORG Fri Jul 10 16:38:04 2009 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 BE026106564A; Fri, 10 Jul 2009 16:38:04 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id A94348FC1C; Fri, 10 Jul 2009 16:38:04 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp026.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KMK008NYRIIAD80@asmtp026.mac.com>; Fri, 10 Jul 2009 09:37:31 -0700 (PDT) From: Marcel Moolenaar In-reply-to: <20090709222420.GE2438@garage.freebsd.pl> Date: Fri, 10 Jul 2009 09:37:30 -0700 Message-id: <0903FECF-3D0D-430E-9E93-C6DC00CA1BC5@mac.com> References: <20090709200102.GA2438@garage.freebsd.pl> <20090709222420.GE2438@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1068) Cc: freebsd-geom@freebsd.org Subject: Re: glabel and real disk IDs 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: Fri, 10 Jul 2009 16:38:05 -0000 On Jul 9, 2009, at 3:24 PM, Pawel Jakub Dawidek wrote: >> I see ZFS getting confused when disks are shuffled around. >> The confusion is the result of having device paths stored >> in the ZFS label match the device name of some other vdev >> that part of the same pool. >> >> Replacing a device with itself doesn't help, because ZFS >> complains that the vdev is part of an active pool in that >> case. It seems that only labels will work here... > > Solaris is using device names stored in ZFS label and if this is not > the > drive it was looking for, it is doing ID-to-path translation to find > new > path name. On FreeBSD on the other hand (after upgrade to v13) I > gave up > doing similar thing because disk IDs weren't available from all disk > device drivers (I implemented it for ATA and I received no help with > other drivers). Currently the idea is to just go through all GEOM > providers looking for proper ZFS metadata (think of it as manual > tasting), so even if device name changes, ZFS should be able to locate > it. If there are still problems locating the disk, there simply > might be > a bug in the code of some sort. Disks are found correctly, it's just that ZFS' internal state is messed up. It uses both the device special file name and the stored vdev path and as such can end up with multiple VDEVs of the same name. As such, some VDEVs are marked as corrupted/faulted. I can reproduce it if you're interested. FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-geom@FreeBSD.ORG Fri Jul 10 19:03:18 2009 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 02A0E106566B for ; Fri, 10 Jul 2009 19:03:18 +0000 (UTC) (envelope-from jeff+freebsd@wagsky.com) Received: from mail.wagsky.com (wildside.wagsky.com [75.101.96.15]) by mx1.freebsd.org (Postfix) with ESMTP id CC6728FC14 for ; Fri, 10 Jul 2009 19:03:17 +0000 (UTC) (envelope-from jeff+freebsd@wagsky.com) Received: from [192.168.208.129] (mail.guidewire.com [69.108.213.131]) by mail.wagsky.com (Postfix) with ESMTPSA id 37BDA1E4192; Fri, 10 Jul 2009 12:03:17 -0700 (PDT) Message-ID: <4A579076.5070008@wagsky.com> Date: Fri, 10 Jul 2009 12:03:18 -0700 From: Jeff Kletsky User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: freebsd-geom@freebsd.org References: <4A578E3F.8050305@wagsky.com> In-Reply-To: <4A578E3F.8050305@wagsky.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: 7.x and 8.0 gpt and gpart GPT PMBR prevents Intel boot 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: Fri, 10 Jul 2009 19:03:18 -0000 It appears to me that the PMBR being used both by gpt and gpart is causing boot problems with current Intel hardware. There appear to be two issues that can cause difficulties: * The "start" of the PMBR is 0xffffff * The PMBR is not marked "bootable" by gpt or gpart In particular, it has been confirmed that it is not possible to format a GPT drive that will boot on an Intel D945GCLF2 with current BIOS (and may be the causes for the observed "freezes" at boot). Both these issues have been previously documented: These two PMBR excerpts illustrate the changes required: This is the "stock" PMBR generated by gpart for a 500 GB SATA drive. It does *not* allow the BIOS to boot.(FreeBSD 7.2-RELEASE-p2) 000001b0: 9090 9090 9090 9090 0000 0000 0000 00ff ................ 000001c0: ffff eeff ffff 0100 0000 2e60 383a 0000 ...........`8:.. 000001d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000001e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000001f0: 0000 0000 0000 0000 0000 0000 0000 55aa ..............U. This is a hand-modified version of the PMBR installed on the same drive that does permit the BIOS to boot. 000001b0: 9090 9090 9090 9090 0000 0000 0000 8001 ................ 000001c0: 0100 eeff ffff 0100 0000 2e60 383a 0000 ...........`8:.. 000001d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000001e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000001f0: 0000 0000 0000 0000 0000 0000 0000 55aa ..............U. Note that the "bootable" flag has been set (0x80) and the start of the partition has been set to the beginning of the disk (0x010100). Without the 0x80 flag also set, the D945GCLF2 BIOS does not identify any bootable drives. The Intel specification for EFI boot does indicate (pp 374-375) that 0xffffff is to be used when the start of the partition can't be represented using CHS notation. However, this PMBR refers to the entire disk, arguably to prevent legacy systems from overwriting it (Protective Master Boot Record), but apparently also "reputable" BIOS manufacturers are producing current systems that key off the information as well. The PR indicates patches for the CHS issue for gpt. For gpart, the code is in /usr/src/sys/geom/part/g_part_gpt.c and, I believe, should be modified to read le16enc(table->mbr + DOSMAGICOFFSET, DOSMAGIC); table->mbr[DOSPARTOFF + 1] = 0x01; /* shd */ table->mbr[DOSPARTOFF + 2] = 0x01; /* ssect */ table->mbr[DOSPARTOFF + 3] = 0x00; /* scyl */ table->mbr[DOSPARTOFF + 4] = 0xee; /* typ */ table->mbr[DOSPARTOFF + 5] = 0xff; /* ehd */ table->mbr[DOSPARTOFF + 6] = 0xff; /* esect */ table->mbr[DOSPARTOFF + 7] = 0xff; /* ecyl */ le32enc(table->mbr + DOSPARTOFF + 8, 1); /* start */ le32enc(table->mbr + DOSPARTOFF + 12, MIN(last, 0xffffffffLL)); which will make it consistent with MBR content for the first partition on Windows machines (protecting GPT drives from inadvertent modification on non-GPT-aware platforms), as well as the patch suggested in PR 115406. (Code still unmodified in HEAD v1.16) As to marking the partition bootable, there is a question of where the most appropriate place might be and if a flag to override should be made available. In my opinion, it should be so marked when a GPT boot segment is added to the drive as well as when either drive-level or partition-level boot code is written, with a command-line option to not change the "bootable" flag in the PMBR for these conditions. In my opinion, these issues should be considered for inclusion in the 8.0-RELEASE -- at the very least, the 0xffffff issue, as it cannot easily be resolved from the command line. Thanks, Jeff From owner-freebsd-geom@FreeBSD.ORG Fri Jul 10 19:39:02 2009 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 AF895106566B for ; Fri, 10 Jul 2009 19:39:02 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206192061.chello.pl [87.206.192.61]) by mx1.freebsd.org (Postfix) with ESMTP id E5F948FC08 for ; Fri, 10 Jul 2009 19:39:00 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 283CD45E86; Fri, 10 Jul 2009 21:38:59 +0200 (CEST) Received: from localhost (chello087206192061.chello.pl [87.206.192.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 6AAA545C99; Fri, 10 Jul 2009 21:38:53 +0200 (CEST) Date: Fri, 10 Jul 2009 21:39:05 +0200 From: Pawel Jakub Dawidek To: Marcel Moolenaar Message-ID: <20090710193905.GA1463@garage.freebsd.pl> References: <20090709200102.GA2438@garage.freebsd.pl> <20090709222420.GE2438@garage.freebsd.pl> <0903FECF-3D0D-430E-9E93-C6DC00CA1BC5@mac.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline In-Reply-To: <0903FECF-3D0D-430E-9E93-C6DC00CA1BC5@mac.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-geom@freebsd.org Subject: Re: glabel and real disk IDs 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: Fri, 10 Jul 2009 19:39:02 -0000 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 10, 2009 at 09:37:30AM -0700, Marcel Moolenaar wrote: >=20 > On Jul 9, 2009, at 3:24 PM, Pawel Jakub Dawidek wrote: > >>I see ZFS getting confused when disks are shuffled around. > >>The confusion is the result of having device paths stored > >>in the ZFS label match the device name of some other vdev > >>that part of the same pool. > >> > >>Replacing a device with itself doesn't help, because ZFS > >>complains that the vdev is part of an active pool in that > >>case. It seems that only labels will work here... > > > >Solaris is using device names stored in ZFS label and if this is not =20 > >the > >drive it was looking for, it is doing ID-to-path translation to find =20 > >new > >path name. On FreeBSD on the other hand (after upgrade to v13) I =20 > >gave up > >doing similar thing because disk IDs weren't available from all disk > >device drivers (I implemented it for ATA and I received no help with > >other drivers). Currently the idea is to just go through all GEOM > >providers looking for proper ZFS metadata (think of it as manual > >tasting), so even if device name changes, ZFS should be able to locate > >it. If there are still problems locating the disk, there simply =20 > >might be > >a bug in the code of some sort. >=20 > Disks are found correctly, it's just that ZFS' internal > state is messed up. It uses both the device special file > name and the stored vdev path and as such can end up with > multiple VDEVs of the same name. As such, some VDEVs are > marked as corrupted/faulted. >=20 > I can reproduce it if you're interested. I am, but I'm leaving tomorrow and I'll be out of e-mail probably for the next two weeks. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFKV5jZForvXbEpPzQRAr03AJsF921Ea0XXYQCq9gCcoyD+AD/9RACfUfgI 81nNqiHAL+q5drV81T47IZ0= =s6SN -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG--