From owner-freebsd-geom@FreeBSD.ORG Mon Oct 1 11:07:17 2012 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8ABEF106567E for ; Mon, 1 Oct 2012 11:07:17 +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 6B6F78FC18 for ; Mon, 1 Oct 2012 11:07:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q91B7H6T024965 for ; Mon, 1 Oct 2012 11:07:17 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q91B7GQH024963 for freebsd-geom@FreeBSD.org; Mon, 1 Oct 2012 11:07:16 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Oct 2012 11:07:16 GMT Message-Id: <201210011107.q91B7GQH024963@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, 01 Oct 2012 11:07:17 -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/170038 geom [geom] geom_mirror always starts degraded after reboot o kern/169539 geom [geom] [patch] fix ability to run gmirror on MSI MegaR a bin/169077 geom bsdinstall(8) does not use partition labels in /etc/fs f kern/165745 geom [geom] geom_multipath page fault on removed drive o kern/165428 geom [glabel][patch] Add xfs support to glabel o kern/164254 geom [geom] gjournal not stopping on GPT partitions o kern/164252 geom [geom] gjournal overflow o kern/164143 geom [geom] Partition table not recognized after upgrade R8 a kern/163020 geom [geli] [patch] enable the Camellia-XTS on GEOM ELI o kern/162690 geom [geom] gpart label changes only take effect after a re o kern/162010 geom [geli] panic: Provider's error should be set (error=0) o kern/161979 geom [geom] glabel doesn't update after newfs, and glabel s o kern/161752 geom [geom] glabel(8) doesn't get gpt label change o bin/161677 geom gpart(8) Probably bug in gptboot o kern/160562 geom [geom][patch] Allow to insert new component to geom_ra o kern/160409 geom [geli] failed to attach provider f kern/159595 geom [geom] [panic] panic on gmirror unload in vbox [regres f kern/159414 geom [isp] isp(4)+gmultipath(8) : removing active fiber pat p kern/158398 geom [headers] [patch] includes o kern/158197 geom [geom] geom_cache with size>1000 leads to panics o kern/157879 geom [libgeom] [regression] ABI change without version bump o kern/157863 geom [geli] kbdmux prevents geli passwords from being enter o kern/157739 geom [geom] GPT labels with geom_multipath o kern/157724 geom [geom] gpart(8) 'add' command must preserve gap for sc o kern/157723 geom [geom] GEOM should not process 'c' (raw) partitions fo o kern/157108 geom [gjournal] dumpon(8) fails on gjournal providers o kern/155994 geom [geom] Long "Suspend time" when reading large files fr o kern/154226 geom [geom] GEOM label does not change when you modify them o kern/150858 geom [geom] [geom_label] [patch] glabel(8) is not compatibl o kern/150626 geom [geom] [gjournal] gjournal(8) destroys label o kern/150555 geom [geom] gjournal unusable on GPT partitions o kern/150334 geom [geom] [udf] [patch] geom label does not support UDF o kern/149762 geom volume labels with rogue characters o bin/149215 geom [panic] [geom_part] gpart(8): Delete linux's slice via o kern/147667 geom [gmirror] Booting with one component of a gmirror, the o kern/145818 geom [geom] geom_stat_open showing cached information for n o kern/145042 geom [geom] System stops booting after printing message "GE o kern/143455 geom gstripe(8) in RELENG_8 (31st Jan 2010) broken o kern/142563 geom [geom] [hang] ioctl freeze in zpool o kern/141740 geom [geom] gjournal(8): g_journal_destroy concurrent error o kern/140352 geom [geom] gjournal + glabel not working o kern/135898 geom [geom] Severe filesystem corruption - large files or l o kern/134113 geom [geli] Problem setting secondary GELI key 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 bin/131415 geom [geli] keystrokes are unregulary sent to Geli when typ o kern/131353 geom [geom] gjournal(8) kernel lock 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 kern/127420 geom [geom] [gjournal] [panic] Journal overflow on gmirrore 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/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123122 geom [geom] GEOM / gjournal kernel lock o kern/122738 geom [geom] gmirror list "losts consumers" after gmirror de o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120091 geom [geom] [geli] [gjournal] geli does not prompt for pass 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 f kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to 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 o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o bin/86388 geom [geom] [geom_part] periodic(8) daily should backup gpa o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu 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. 74 problems total. From owner-freebsd-geom@FreeBSD.ORG Mon Oct 1 10:29:06 2012 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 DBEAE1065700 for ; Mon, 1 Oct 2012 10:29:05 +0000 (UTC) (envelope-from dark@rambler-co.ru) Received: from dark.park.rambler.ru (dark.park.rambler.ru [81.19.64.109]) by mx1.freebsd.org (Postfix) with ESMTP id 68A0C8FC14 for ; Mon, 1 Oct 2012 10:29:04 +0000 (UTC) Received: from dark.park.rambler.ru (localhost [127.0.0.1]) by dark.park.rambler.ru (8.14.5/8.14.5) with ESMTP id q91AAelL030840; Mon, 1 Oct 2012 14:10:40 +0400 (MSK) (envelope-from dark@rambler-co.ru) Message-ID: <50696C20.3020704@rambler-co.ru> Date: Mon, 01 Oct 2012 14:10:40 +0400 From: Konstantin Kukushkin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120919 Thunderbird/15.0.1 MIME-Version: 1.0 To: Warren Block References: <50663866.9070001@delphij.net> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 01 Oct 2012 11:50:30 +0000 Cc: d@delphij.net, freebsd-geom@freebsd.org Subject: Re: Simple way to clear arbitrary drive metadata? 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, 01 Oct 2012 10:29:06 -0000 29.09.2012 21:27, Warren Block пишет: > On Fri, 28 Sep 2012, Xin Li wrote: > >> On 09/28/12 15:21, Warren Block wrote: >>> Last night, I found that the remnants of a GPT backup table on an >>> MBR drive prevented it from booting. When reusing drives from old >>> mirrors, old mirror metadata can be a problem also. And there may >>> be old hardware RAID metadata at the end of the drive. >>> >>> It would be great if dd understood negative seek values. This >>> would get most of that old metadata: >>> >>> dd if=/dev/zero of=/dev/ada8 seek=-34 >>> >>> ...but dd does not understand negative seek values. (Been on my >>> list for a while to look at that.) >>> >>> Which leaves things like >>> >>> diskinfo ada8 | cut -f4 (subtract 34) dd if=/dev/zero of=/dev/ada8 >>> seek=(calculated value) >>> >>> That can be done in one command line with bc and backticks, but >>> it's not clear or elegant. gpart can clear secondary GPT tables, >>> but I'm pretty sure it won't wipe out that space unless it actually >>> is a GPT table. Likewise with glabel and gmirror, they're safe >>> because they only touch data they understand. >>> >>> Is there something simpler and more blunt? >> >> I think you can do: >> >> gpart destroy -F ada8 >> gpart create -s gpt ada8 >> gpart destroy -F ada8 >> >> The second 'create' will write an empty partition table to the >> secondary table. > > Nice! It works perfectly for GPT and glabel metadata. > > gmirror is a problem. If the gmirror kernel module is loaded, drives > with gmirror metadata create a mirror. GEOM prevents writes to the > drive then. sysctl kern.geom.debugflags=16 allows writes, but the > mirror is still in memory and running. 'gmirror stop' (which the system > also does on shutdown) helpfully writes the whole metadata block back to > the drive. After reboot, it's right back where it was. > > Seems like the only way to deal with gmirror is to have the user check > for it directly, and stop the mirror if the attached drive is a member. You may use 'geom clear' command to clear metadata from disk/partition/other GEOM provider. This will work only on stopped mirrors or while geom_mirror not loaded, of course. For gmirror you can 'remove' component from running mirror (even if the component is last). Metadata will cleared after removing, so gmirror remove ' is very usable. You can determine what GEOMs metadata living on disk $disk using command 'geom dump', like this: for class in mirror stripe concat raid3; do geom $class dump $disk done > Probably the same for graid, but I don't know if I have a system where I > can test that. > _______________________________________________ > freebsd-geom@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-geom > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" -- С уважением, Константин Кукушкин, Rambler Internet Holding mailto:dark@rambler-co.ru тел.: 8 (495) 785-17-00#2129 From owner-freebsd-geom@FreeBSD.ORG Mon Oct 1 13:03:26 2012 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 8829D106566B for ; Mon, 1 Oct 2012 13:03:26 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 296D68FC15 for ; Mon, 1 Oct 2012 13:03:25 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q91D3IrF094010; Mon, 1 Oct 2012 07:03:18 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q91D3I4r094007; Mon, 1 Oct 2012 07:03:18 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Mon, 1 Oct 2012 07:03:18 -0600 (MDT) From: Warren Block To: Konstantin Kukushkin In-Reply-To: <50696C20.3020704@rambler-co.ru> Message-ID: References: <50663866.9070001@delphij.net> <50696C20.3020704@rambler-co.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Mon, 01 Oct 2012 07:03:19 -0600 (MDT) Cc: d@delphij.net, freebsd-geom@freebsd.org Subject: Re: Simple way to clear arbitrary drive metadata? 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, 01 Oct 2012 13:03:26 -0000 On Mon, 1 Oct 2012, Konstantin Kukushkin wrote: >> gmirror is a problem. If the gmirror kernel module is loaded, drives >> with gmirror metadata create a mirror. GEOM prevents writes to the >> drive then. sysctl kern.geom.debugflags=16 allows writes, but the >> mirror is still in memory and running. 'gmirror stop' (which the system >> also does on shutdown) helpfully writes the whole metadata block back to >> the drive. After reboot, it's right back where it was. >> >> Seems like the only way to deal with gmirror is to have the user check >> for it directly, and stop the mirror if the attached drive is a member. > > You may use 'geom clear' command to clear metadata from > disk/partition/other GEOM provider. This will work only on stopped mirrors or > while geom_mirror not loaded, of course. > For gmirror you can 'remove' component from running mirror (even if the > component is last). Metadata will cleared after removing, so gmirror remove > ' is very usable. Yes, that's what I used. This was initially for an update to the gmirror section of the GEOM chapter of the Handbook: http://www.wonkity.com/~wblock/gmirror/geom-mirror.html The problem with gmirror remove or clear is that the user must check to see whether the drive is part of an active mirror to know which command to use. Seems like "remove" should not require the mirror name and would work whether the mirror was active or not. > You can determine what GEOMs metadata living on disk $disk using command > 'geom dump', like this: > for class in mirror stripe concat raid3; do > geom $class dump $disk > done Is there a utility that can do that in the other direction? Given a disk, identify the type of metadata on it? From owner-freebsd-geom@FreeBSD.ORG Wed Oct 3 14:36:03 2012 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B7598106564A; Wed, 3 Oct 2012 14:36:03 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D1B6B8FC0C; Wed, 3 Oct 2012 14:36:02 +0000 (UTC) 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 RAA07164; Wed, 03 Oct 2012 17:35:59 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <506C4D4F.2090909@FreeBSD.org> Date: Wed, 03 Oct 2012 17:35:59 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Steven Hartland References: <505DF1A3.1020809@FreeBSD.org> <80F518854AE34A759D9441AE1A60D2DC@multiplay.co.uk> In-Reply-To: <80F518854AE34A759D9441AE1A60D2DC@multiplay.co.uk> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: zfs zvol: set geom mediasize right at creation time 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, 03 Oct 2012 14:36:03 -0000 on 23/09/2012 04:04 Steven Hartland said the following: > Do you know what the effect of the volblocksize change > will have on a volume who's disk block size changes? > e.g. via a quirk for a 4k disk being added I am not sure that I got your question... My patch doesn't affect neither volblocksize value nor disk block size [geom property]. It changes only stripe size geom property. > I ask as we've testing a patch here which changes ashift to > be based on stripesize instead of sectorsize but in its > current form it has some odd side effects on pools which > are boot pools. > > Said patch is attached for reference. I think that the patch makes sense and would be curious to learn more about the side-effects. -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Wed Oct 3 14:53:24 2012 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 5B4D3106566B for ; Wed, 3 Oct 2012 14:53:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id AB3708FC12 for ; Wed, 3 Oct 2012 14:53:23 +0000 (UTC) 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 RAA07329; Wed, 03 Oct 2012 17:53:20 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <506C5160.4020206@FreeBSD.org> Date: Wed, 03 Oct 2012 17:53:20 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <505DF409.9070908@FreeBSD.org> <505FE141.5070803@yandex.ru> In-Reply-To: <505FE141.5070803@yandex.ru> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-geom@FreeBSD.org Subject: Re: re-tasting of providers held with withering consumers 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, 03 Oct 2012 14:53:24 -0000 on 24/09/2012 07:27 Andrey V. Elsukov said the following: > On 22.09.2012 21:23, Andriy Gapon wrote: >> >> Because removal of withered geoms is done asynchronously, there is a window when >> some provider may require re-tasting (because of media change or size change), >> but it would still be in use by the withering geom. That prevents re-tasting a >> class of that withering geom (for obvious reasons). >> >> The following patch tries to trigger owed re-tasting after the withering >> provider is gone for good: >> http://people.freebsd.org/~avg/geom-withered-retaste.diff > > Hi, Andriy, > > it seems you forgot to include g_renew_provider() implementation into the patch. > Oh, yes, it is as simple as: void g_renew_provider(struct g_provider *pp) { g_topology_assert(); G_VALID_PROVIDER(pp); KASSERT(!(pp->geom->flags & G_GEOM_WITHER), ("renew provider on WITHERing geom(%s) (class %s)", pp->geom->name, pp->geom->class->name)); g_post_event(g_new_provider_event, pp, M_WAITOK, pp, NULL); } I actually borrowed it from a patch of yours :-) -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Sat Oct 6 03:25:27 2012 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 99E1D106566B; Sat, 6 Oct 2012 03:25:27 +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 6B5C68FC0C; Sat, 6 Oct 2012 03:25:27 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q963PRIP059524; Sat, 6 Oct 2012 03:25:27 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q963PQUr059520; Sat, 6 Oct 2012 03:25:26 GMT (envelope-from linimon) Date: Sat, 6 Oct 2012 03:25:26 GMT Message-Id: <201210060325.q963PQUr059520@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-geom@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/171865: [geom] [patch] g_wither_washer() keeping a core busy 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, 06 Oct 2012 03:25:28 -0000 Synopsis: [geom] [patch] g_wither_washer() keeping a core busy Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: linimon Responsible-Changed-When: Sat Oct 6 03:25:16 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=171865