From owner-freebsd-geom@FreeBSD.ORG Mon Oct 22 11:06:35 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 3F82124F for ; Mon, 22 Oct 2012 11:06:35 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.FreeBSD.org [8.8.178.135]) by mx1.freebsd.org (Postfix) with ESMTP id 2620D8FC1D for ; Mon, 22 Oct 2012 11:06:35 +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 q9MB6ZeN044407 for ; Mon, 22 Oct 2012 11:06:35 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q9MB6YpL044405 for freebsd-geom@FreeBSD.org; Mon, 22 Oct 2012 11:06:34 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 22 Oct 2012 11:06:34 GMT Message-Id: <201210221106.q9MB6YpL044405@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 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 11:06:35 -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/171865 geom [geom] [patch] g_wither_washer() keeping a core busy 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. 75 problems total. From owner-freebsd-geom@FreeBSD.ORG Thu Oct 25 06:49:08 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 44779895 for ; Thu, 25 Oct 2012 06:49:08 +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 76F3E8FC12 for ; Thu, 25 Oct 2012 06:49:07 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA04581 for ; Thu, 25 Oct 2012 09:49:05 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TRHFZ-000JYv-Au for freebsd-geom@FreeBSD.org; Thu, 25 Oct 2012 09:49:05 +0300 Message-ID: <5088E0E0.2080307@FreeBSD.org> Date: Thu, 25 Oct 2012 09:49:04 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121013 Thunderbird/16.0.1 MIME-Version: 1.0 To: freebsd-geom@FreeBSD.org Subject: geom access method and g_topology_lock X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 06:49:08 -0000 Is that bad if a geom's access method drops and re-acquires g_topology_lock while doing some internal stuff? Is that allowed at all? The problem is that the following innocent-looking code may become not quite so innocent: g_topology_assert(); g_access(cp, -1, 0, -1); /* a lot might have happened between these two lines */ g_detach(cp); g_destroy_consumer(cp); -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Thu Oct 25 07:28:40 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 8A086F4F; Thu, 25 Oct 2012 07:28:40 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 42AF28FC0A; Thu, 25 Oct 2012 07:28:40 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 03B053B77C; Thu, 25 Oct 2012 07:28:31 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q9P7SVLB028186; Thu, 25 Oct 2012 07:28:31 GMT (envelope-from phk@phk.freebsd.dk) To: Andriy Gapon Subject: Re: geom access method and g_topology_lock In-reply-to: <5088E0E0.2080307@FreeBSD.org> From: "Poul-Henning Kamp" References: <5088E0E0.2080307@FreeBSD.org> Date: Thu, 25 Oct 2012 07:28:31 +0000 Message-ID: <28185.1351150111@critter.freebsd.dk> Cc: freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 07:28:40 -0000 -------- In message <5088E0E0.2080307@FreeBSD.org>, Andriy Gapon writes: >The problem is that the following innocent-looking code may become not quite so >innocent: > >g_topology_assert(); >g_access(cp, -1, 0, -1); >/* a lot might have happened between these two lines */ >g_detach(cp); >g_destroy_consumer(cp); It really depends what "a lot" actually is. It is perfectly legal and acceptable for a consumer to be attached to a provider without holding an access count. But lacking an access count, there are obviously things you cannot do to that provider. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Thu Oct 25 08:36:43 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 64677F1D for ; Thu, 25 Oct 2012 08:36:43 +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 AA7828FC12 for ; Thu, 25 Oct 2012 08:36:42 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA05260; Thu, 25 Oct 2012 11:36:39 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TRIvf-000JfA-0r; Thu, 25 Oct 2012 11:36:39 +0300 Message-ID: <5088FA15.30205@FreeBSD.org> Date: Thu, 25 Oct 2012 11:36:37 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121013 Thunderbird/16.0.1 MIME-Version: 1.0 To: Poul-Henning Kamp Subject: Re: geom access method and g_topology_lock References: <5088E0E0.2080307@FreeBSD.org> <28185.1351150111@critter.freebsd.dk> In-Reply-To: <28185.1351150111@critter.freebsd.dk> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 08:36:43 -0000 on 25/10/2012 10:28 Poul-Henning Kamp said the following: > -------- > In message <5088E0E0.2080307@FreeBSD.org>, Andriy Gapon writes: Unfortunately the questions got stripped :-) >> The problem is that the following innocent-looking code may become not quite so >> innocent: >> >> g_topology_assert(); >> g_access(cp, -1, 0, -1); >> /* a lot might have happened between these two lines */ >> g_detach(cp); >> g_destroy_consumer(cp); > > > It really depends what "a lot" actually is. > > It is perfectly legal and acceptable for a consumer to be attached to a provider > without holding an access count. > > But lacking an access count, there are obviously things you cannot do to that > provider. To be less cryptic: there is a piece of code that tries to re-use the consumer in certain situations. Basically, in addition to the above snippet there is a different snippet in a different function (oversimplified version): g_topology_assert(); LIST_FOREACH(cp, &gp->consumer, consumer) { if (cp->provider == pp) break; } if (cp != NULL) g_access(cp, 1, 0, 1) Both pieces look sane and non-racy (because of g_topology_assert) until we allow g_access (some geom access method, rather) to drop the topology lock. Hence my original questions. I would also accept that such a re-use of a consumer is a bad idea on its own. -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Thu Oct 25 08:41:20 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 CDB48386; Thu, 25 Oct 2012 08:41:20 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 857C78FC1A; Thu, 25 Oct 2012 08:41:20 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id E96C73B74C; Thu, 25 Oct 2012 08:41:18 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q9P8fIsh070961; Thu, 25 Oct 2012 08:41:18 GMT (envelope-from phk@phk.freebsd.dk) To: Andriy Gapon Subject: Re: geom access method and g_topology_lock In-reply-to: <5088FA15.30205@FreeBSD.org> From: "Poul-Henning Kamp" References: <5088E0E0.2080307@FreeBSD.org> <28185.1351150111@critter.freebsd.dk> <5088FA15.30205@FreeBSD.org> Date: Thu, 25 Oct 2012 08:41:18 +0000 Message-ID: <70960.1351154478@critter.freebsd.dk> Cc: freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 08:41:20 -0000 -------- In message <5088FA15.30205@FreeBSD.org>, Andriy Gapon writes: >Both pieces look sane and non-racy (because of g_topology_assert) until we allow >g_access (some geom access method, rather) to drop the topology lock. You lost me there. g_access() cannot do its job without holding the topology lock. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Thu Oct 25 08:54:13 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 01E6C6D1 for ; Thu, 25 Oct 2012 08:54:12 +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 4AAF48FC12 for ; Thu, 25 Oct 2012 08:54:11 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA05430; Thu, 25 Oct 2012 11:54:09 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TRJCb-000JgN-As; Thu, 25 Oct 2012 11:54:09 +0300 Message-ID: <5088FE30.2030903@FreeBSD.org> Date: Thu, 25 Oct 2012 11:54:08 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121013 Thunderbird/16.0.1 MIME-Version: 1.0 To: Poul-Henning Kamp Subject: Re: geom access method and g_topology_lock References: <5088E0E0.2080307@FreeBSD.org> <28185.1351150111@critter.freebsd.dk> <5088FA15.30205@FreeBSD.org> <70960.1351154478@critter.freebsd.dk> In-Reply-To: <70960.1351154478@critter.freebsd.dk> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 08:54:13 -0000 on 25/10/2012 11:41 Poul-Henning Kamp said the following: > -------- > In message <5088FA15.30205@FreeBSD.org>, Andriy Gapon writes: > >> Both pieces look sane and non-racy (because of g_topology_assert) until we allow >> g_access (some geom access method, rather) to drop the topology lock. > > You lost me there. > > g_access() cannot do its job without holding the topology lock. > > Will it help if I repeat my original questions: Is that bad if a geom's access method drops and re-acquires g_topology_lock while doing some internal stuff? Is that allowed at all? To clarify, if that's needed, by "geom's access method" I meant the 'access' member with g_access_t type in struct g_geom. -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Thu Oct 25 09:04:48 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 9FAA7FB6; Thu, 25 Oct 2012 09:04:48 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 354078FC14; Thu, 25 Oct 2012 09:04:47 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id D5BD63B080; Thu, 25 Oct 2012 09:04:46 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q9P94kBN094630; Thu, 25 Oct 2012 09:04:46 GMT (envelope-from phk@phk.freebsd.dk) To: Andriy Gapon Subject: Re: geom access method and g_topology_lock In-reply-to: <5088FE30.2030903@FreeBSD.org> From: "Poul-Henning Kamp" References: <5088E0E0.2080307@FreeBSD.org> <28185.1351150111@critter.freebsd.dk> <5088FA15.30205@FreeBSD.org> <70960.1351154478@critter.freebsd.dk> <5088FE30.2030903@FreeBSD.org> Date: Thu, 25 Oct 2012 09:04:46 +0000 Message-ID: <94629.1351155886@critter.freebsd.dk> Cc: freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 09:04:48 -0000 -------- In message <5088FE30.2030903@FreeBSD.org>, Andriy Gapon writes: >on 25/10/2012 11:41 Poul-Henning Kamp said the following: >To clarify, if that's needed, by "geom's access method" I meant the 'access' >member with g_access_t type in struct g_geom. Ahh, sorry, I misinterpreted your question because I though the answer, as posed, would be blindingly obvious. yes, that would not only be bad, that would be VERY BAD. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Thu Oct 25 09:11:50 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 38E844F0 for ; Thu, 25 Oct 2012 09:11:50 +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 7C8758FC14 for ; Thu, 25 Oct 2012 09:11:48 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA05583; Thu, 25 Oct 2012 12:11:47 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TRJTe-000Jhv-Qz; Thu, 25 Oct 2012 12:11:46 +0300 Message-ID: <50890251.8090402@FreeBSD.org> Date: Thu, 25 Oct 2012 12:11:45 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121013 Thunderbird/16.0.1 MIME-Version: 1.0 To: Poul-Henning Kamp Subject: Re: geom access method and g_topology_lock References: <5088E0E0.2080307@FreeBSD.org> <28185.1351150111@critter.freebsd.dk> <5088FA15.30205@FreeBSD.org> <70960.1351154478@critter.freebsd.dk> <5088FE30.2030903@FreeBSD.org> <94629.1351155886@critter.freebsd.dk> In-Reply-To: <94629.1351155886@critter.freebsd.dk> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 09:11:50 -0000 on 25/10/2012 12:04 Poul-Henning Kamp said the following: > -------- > In message <5088FE30.2030903@FreeBSD.org>, Andriy Gapon writes: >> on 25/10/2012 11:41 Poul-Henning Kamp said the following: > >> To clarify, if that's needed, by "geom's access method" I meant the 'access' >> member with g_access_t type in struct g_geom. > > Ahh, sorry, I misinterpreted your question because I though the answer, as posed, > would be blindingly obvious. > > yes, that would not only be bad, that would be VERY BAD. I suspected as much. Thank you for the clear answer! Now need to think hard how to avoid doing that nasty thing... -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Thu Oct 25 09:15:30 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 F317A677; Thu, 25 Oct 2012 09:15:29 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id A9FFA8FC14; Thu, 25 Oct 2012 09:15:29 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 28B6D3B783; Thu, 25 Oct 2012 09:15:28 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q9P9FS8b003498; Thu, 25 Oct 2012 09:15:28 GMT (envelope-from phk@phk.freebsd.dk) To: Andriy Gapon Subject: Re: geom access method and g_topology_lock In-reply-to: <50890251.8090402@FreeBSD.org> From: "Poul-Henning Kamp" References: <5088E0E0.2080307@FreeBSD.org> <28185.1351150111@critter.freebsd.dk> <5088FA15.30205@FreeBSD.org> <70960.1351154478@critter.freebsd.dk> <5088FE30.2030903@FreeBSD.org> <94629.1351155886@critter.freebsd.dk> <50890251.8090402@FreeBSD.org> Date: Thu, 25 Oct 2012 09:15:28 +0000 Message-ID: <3497.1351156528@critter.freebsd.dk> Cc: freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 09:15:30 -0000 -------- In message <50890251.8090402@FreeBSD.org>, Andriy Gapon writes: >Now need to think hard how to avoid doing that nasty thing... Nothing prevents a GEOM from having multiple consumers attached to the same provider. That opens a lot of interesting options. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Fri Oct 26 09:00:14 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 6F8A4FB9; Fri, 26 Oct 2012 09:00:14 +0000 (UTC) (envelope-from prvs=1646183d11=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id A82068FC1C; Fri, 26 Oct 2012 09:00:12 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50000835132.msg; Fri, 26 Oct 2012 10:00:11 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Fri, 26 Oct 2012 10:00:11 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1646183d11=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <6B3FDA029094479C8FD44EF4B435CBF4@multiplay.co.uk> From: "Steven Hartland" To: "Andriy Gapon" References: <505DF1A3.1020809@FreeBSD.org> <80F518854AE34A759D9441AE1A60D2DC@multiplay.co.uk> <506C4D4F.2090909@FreeBSD.org> Subject: Re: zfs zvol: set geom mediasize right at creation time Date: Fri, 26 Oct 2012 10:00:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-fs@FreeBSD.org, freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 09:00:14 -0000 ----- Original Message ----- From: "Andriy Gapon" > 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. Right finally tracked the problem down. The issue was that opening a pool which has multiple vdev's vdev_open is called where vd->vdev_asize != 0. This means the vd->vdev_ashift calculation is done on existing devices despite the comment:- /* * This is the first-ever open, so use the computed values. * For testing purposes, a higher ashift can be requested. */ Due to the alignment requirement check below this causes the zpool open to fail. I've now fixed this by moving the use dashift into the volume label code which is only run on creation. PR with updated patch submitted:- http://www.freebsd.org/cgi/query-pr.cgi?pr=173115 Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk.