From owner-freebsd-geom@FreeBSD.ORG Mon Sep 17 11:07:05 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 CEC231065686 for ; Mon, 17 Sep 2012 11:07:05 +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 B0AA48FC28 for ; Mon, 17 Sep 2012 11:07:05 +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 q8HB75eK004439 for ; Mon, 17 Sep 2012 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q8HB75sh004437 for freebsd-geom@FreeBSD.org; Mon, 17 Sep 2012 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Sep 2012 11:07:05 GMT Message-Id: <201209171107.q8HB75sh004437@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, 17 Sep 2012 11:07:05 -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 Tue Sep 18 13:28:55 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 C05B21065672; Tue, 18 Sep 2012 13:28:55 +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 C6A468FC22; Tue, 18 Sep 2012 13:28:54 +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 QAA19972; Tue, 18 Sep 2012 16:28:53 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <50587714.8030300@FreeBSD.org> Date: Tue, 18 Sep 2012 16:28:52 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120830 Thunderbird/15.0 MIME-Version: 1.0 To: Edward Tomasz Napierala X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-geom@FreeBSD.org Subject: g_resize_provider_event and withering geoms 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, 18 Sep 2012 13:28:55 -0000 Edward, I think that the resize event handler should not skip (re-)taste for withering geoms. What do you think? diff --git a/sys/geom/geom_subr.c b/sys/geom/geom_subr.c index 5342aba..56807fe 100644 --- a/sys/geom/geom_subr.c +++ b/sys/geom/geom_subr.c @@ -680,6 +680,7 @@ g_resize_provider_event(void *arg, int flag) continue; LIST_FOREACH(cp, &pp->consumers, consumers) if (cp->geom->class == mp && + (cp->geom->flags & G_GEOM_WITHER) == 0 && (cp->flags & G_CF_ORPHAN) == 0) break; if (cp != NULL) -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Wed Sep 19 04:04:31 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 A39A8106566B for ; Wed, 19 Sep 2012 04:04:31 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7697B8FC0A for ; Wed, 19 Sep 2012 04:04:31 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id q8J44UJV030072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Sep 2012 21:04:30 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id q8J44UsJ030071 for freebsd-geom@FreeBSD.org; Tue, 18 Sep 2012 21:04:30 -0700 (PDT) (envelope-from jmg) Date: Tue, 18 Sep 2012 21:04:30 -0700 From: John-Mark Gurney To: freebsd-geom@FreeBSD.org Message-ID: <20120919040430.GF19036@funkthat.com> Mail-Followup-To: freebsd-geom@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 18 Sep 2012 21:04:30 -0700 (PDT) Cc: Subject: geli and BIO_FLUSH and/or BIO_ORDERED issue? 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, 19 Sep 2012 04:04:31 -0000 I was looking at geli and I'm not sure if it's implementing BIO_FLUSH and/or BIO_ORDERED properly... >From my understanding is the BIO_ORDERED is suppose to wait for the previous _WRITES to complete before returning so that you can ensure that data is on disk, i.e. _ORDERED is set on a BIO_FLUSH... BIO_ORDERED is handled by diskq_* code such that when you add an _ORDERED command, all commands are put after it, but there doesn't appear to be any code to ensure that an _ORDERED command waits for prevoius pending commands to complete.. This is extra obvious in eli in that a _FLUSH is immediately dispatched, even when there may be _WRITEs that haven't been finished encrypting and sent down to the disk to get _FLUSHed... Any comments about this? Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-geom@FreeBSD.ORG Thu Sep 20 16:53:38 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 7B2AB1065670; Thu, 20 Sep 2012 16:53:38 +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 9EBBD8FC15; Thu, 20 Sep 2012 16:53:37 +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 TAA18824; Thu, 20 Sep 2012 19:53:35 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <505B4A0E.80403@FreeBSD.org> Date: Thu, 20 Sep 2012 19:53:34 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120830 Thunderbird/15.0 MIME-Version: 1.0 To: Alexander Motin , freebsd-geom@FreeBSD.org X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: g_retaste_event: potential problem with g_wither_geom and re-taste 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, 20 Sep 2012 16:53:38 -0000 Alexander, I think that g_retaste_event may have a problem along the lines that we discussed on IRC but in a little bit different context. Namely, if we find a connected non-orphaned consumer belonging to a geom of a target class, then we mark the consumer as orphaned and call g_wither_geom on its geom. Then we call taste method of the target class on the provider in question. But since g_wither_geom initiates an asynchronous operation the withered geom will still exist and we may create a new "duplicate" geom beside it. That could result in resource conflict or in confusion in the upper layers. E.g. if the class would be geom_dev, then the newly attached geom won't be able to create a devfs entry, because the withering geom still has it. I hope that miss something in this scenario... P.S. Also, the code seems to wither/orphan only the first of qualified geoms/consumers. I am not sure if it's safe to assume that only one geom of a given class could be attached to a provider. Hypothetically different instances/geoms of the same class could be using some provider for different reasons and purposes. -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Thu Sep 20 20:08:34 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 B8FF31065672; Thu, 20 Sep 2012 20:08:34 +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 D95968FC08; Thu, 20 Sep 2012 20:08:33 +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 XAA19895; Thu, 20 Sep 2012 23:08:32 +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 1TEn31-000F2I-Oq; Thu, 20 Sep 2012 23:08:31 +0300 Message-ID: <505B77BD.9080900@FreeBSD.org> Date: Thu, 20 Sep 2012 23:08:29 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120913 Thunderbird/15.0.1 MIME-Version: 1.0 To: Alexander Motin , freebsd-geom@FreeBSD.org References: <505B4A0E.80403@FreeBSD.org> In-Reply-To: <505B4A0E.80403@FreeBSD.org> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: g_retaste_event: potential problem with g_wither_geom and re-taste 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, 20 Sep 2012 20:08:34 -0000 on 20/09/2012 19:53 Andriy Gapon said the following: > > Alexander, > > I think that g_retaste_event may have a problem along the lines that we discussed > on IRC but in a little bit different context. > Namely, if we find a connected non-orphaned consumer belonging to a geom of a > target class, then we mark the consumer as orphaned and call g_wither_geom on its > geom. Then we call taste method of the target class on the provider in question. > But since g_wither_geom initiates an asynchronous operation the withered geom will > still exist and we may create a new "duplicate" geom beside it. That could result > in resource conflict or in confusion in the upper layers. > E.g. if the class would be geom_dev, then the newly attached geom won't be able to > create a devfs entry, because the withering geom still has it. > I hope that miss something in this scenario... ^- this should have been 'I missed' And indeed, what I missed is that retaste mechanism is not an infrastructural thing in GEOM, but rather it is used by code related to specific GEOM classes to trigger re-tasting by those classes. So that code should already know what it is going and when it is doing that. > P.S. > Also, the code seems to wither/orphan only the first of qualified geoms/consumers. > I am not sure if it's safe to assume that only one geom of a given class could be > attached to a provider. Hypothetically different instances/geoms of the same > class could be using some provider for different reasons and purposes. > Ditto here. -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Sat Sep 22 04:20:50 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 285E11065677 for ; Sat, 22 Sep 2012 04:20:50 +0000 (UTC) (envelope-from jacks.1785@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id E95C58FC14 for ; Sat, 22 Sep 2012 04:20:49 +0000 (UTC) Received: by ieak10 with SMTP id k10so5665571iea.13 for ; Fri, 21 Sep 2012 21:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=aNNx4qyzpIsKyo+5TyQxIFG9pu1eL5CldVUUDknuy+s=; b=O5sf5A5YAqqen+ggHQ5+8UBUxJ2FrOoYrx+mo1bMGNOuBDG2eeppgd+SEL0tMXOCbp ONzj9BT1ZvYuACj1r4snEq1BECme4HxBnN+Y2RIb2X5sJz+OiMWgcEe8JH7bQxzEiNi0 tvSYIDRI1AvxE2l5+r040wqtQfErNYmHbIyO9+EssOTl1PWtAFeafDe/71gSvWpIIbeS buxoUYSCiIcUjkD6CLp3tum9reEQ6CH+pzqriMNI3G1QKUygghHHoSTNTQzU2x21N9WZ BAcDAQllPun4b8gEIL2YkEcTK7qHViBPwqsGnm1CxFHh2wkCKG+87OB6tsaNWmKU3JRW I/lw== MIME-Version: 1.0 Received: by 10.50.100.166 with SMTP id ez6mr267172igb.55.1348287649141; Fri, 21 Sep 2012 21:20:49 -0700 (PDT) Received: by 10.64.44.105 with HTTP; Fri, 21 Sep 2012 21:20:49 -0700 (PDT) Date: Sat, 22 Sep 2012 09:50:49 +0530 Message-ID: From: Jack To: freebsd-geom@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: GEOM and CAM pass behaviour 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, 22 Sep 2012 04:20:50 -0000 Hi all, I would like to know 2 things regarding geom and cam pass driver behaviour. It would be helpful if someone could educate me regarding this. Consider the case where a scsi/ata tape/hard drive is attached to the system after the FreeBSD is booted(from different drive) completely. 1. Is it true that GEOM layer will always taste the (hard drive/tape drive)device whether we access device via cam pass driver or do block access. In other words, say if we never do a block access on the selected device, and we only access this device via cam pass driver, will then Geom will ever have to taste(e.g. for partition table, etc. or for other purposes) this device.? or is it something like, as soon as the device is attached, geom layer will always taste it - it doesn't matter how we access the device. 2. Also, is it possible that while a process is accessing the selected device via cam pass driver, the block access is also possible at that same time, (by same or different process) to that same device. I know that when a process is accessing the device via block access, it is possible for another(or even same) process to access that same device via cam pass driver, but I would like to know whether the other way is true also. Thanks. -- Jack From owner-freebsd-geom@FreeBSD.ORG Sat Sep 22 16:20:08 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 544FA1065696 for ; Sat, 22 Sep 2012 16:20:08 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 190088FC08 for ; Sat, 22 Sep 2012 16:20:07 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 9F151D94 for ; Sat, 22 Sep 2012 18:19:09 +0200 (CEST) Date: Sat, 22 Sep 2012 18:20:26 +0200 From: Pawel Jakub Dawidek To: freebsd-geom@FreeBSD.org Message-ID: <20120922162025.GE1454@garage.freebsd.pl> References: <20120919040430.GF19036@funkthat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ryJZkp9/svQ58syV" Content-Disposition: inline In-Reply-To: <20120919040430.GF19036@funkthat.com> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: geli and BIO_FLUSH and/or BIO_ORDERED issue? 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, 22 Sep 2012 16:20:08 -0000 --ryJZkp9/svQ58syV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 18, 2012 at 09:04:30PM -0700, John-Mark Gurney wrote: > I was looking at geli and I'm not sure if it's implementing BIO_FLUSH > and/or BIO_ORDERED properly... >=20 > >From my understanding is the BIO_ORDERED is suppose to wait for the > previous _WRITES to complete before returning so that you can ensure > that data is on disk, i.e. _ORDERED is set on a BIO_FLUSH... >=20 > BIO_ORDERED is handled by diskq_* code such that when you add an _ORDERED > command, all commands are put after it, but there doesn't appear to > be any code to ensure that an _ORDERED command waits for prevoius > pending commands to complete.. >=20 > This is extra obvious in eli in that a _FLUSH is immediately dispatched, > even when there may be _WRITEs that haven't been finished encrypting and > sent down to the disk to get _FLUSHed... >=20 > Any comments about this? Hmm, BIO_ORDERED was introduced pretty recently and GEOM classes were not updated to honour it, but it also seems to be to complex to handle in GEOM classes. I wonder if we could hold off new writes and wait for the in-progress writes in GEOM if we spot BIO_ORDERED request without the need to implement this logic in GEOM classes. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --ryJZkp9/svQ58syV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBd5UkACgkQForvXbEpPzS/RQCgsP3zr1ssR/+lH/TUHFeHH9di eL8AnjUWMwvqrRkou4YKDe1snt5r/cVR =rs+F -----END PGP SIGNATURE----- --ryJZkp9/svQ58syV-- From owner-freebsd-geom@FreeBSD.ORG Sat Sep 22 17:07:55 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 211771065670 for ; Sat, 22 Sep 2012 17:07:55 +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 519DA8FC15 for ; Sat, 22 Sep 2012 17:07:54 +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 UAA07546 for ; Sat, 22 Sep 2012 20:07:52 +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 1TFTBI-000NUY-Fm for freebsd-geom@FreeBSD.org; Sat, 22 Sep 2012 20:07:52 +0300 Message-ID: <505DF067.9020700@FreeBSD.org> Date: Sat, 22 Sep 2012 20:07:51 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120913 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-geom@FreeBSD.org X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Subject: g_part_taste: directly destroy consumer and geom when tasting fails 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, 22 Sep 2012 17:07:55 -0000 What do you think about the following change? The withering also has unpleasant side effect of preventing subsequent retaste of a provider if it quickly changes before the withering "taster" geom and consumer are actually destroyed. commit 660581a09ee5e7a66a272c8cf4c549170a73a012 Author: Andriy Gapon Date: Wed Sep 19 20:11:32 2012 +0300 g_part_taste: directly destroy consumer and geom here, no need for withering diff --git a/sys/geom/part/g_part.c b/sys/geom/part/g_part.c index 846cd03..9e95e7e 100644 --- a/sys/geom/part/g_part.c +++ b/sys/geom/part/g_part.c @@ -1885,7 +1885,10 @@ g_part_taste(struct g_class *mp, struct g_provider *pp, int flags __unused) if (error == 0) error = g_access(cp, 1, 0, 0); if (error != 0) { - g_part_wither(gp, error); + if (cp->provider) + g_detach(cp); + g_destroy_consumer(cp); + g_destroy_geom(gp); return (NULL); } @@ -1945,7 +1948,9 @@ g_part_taste(struct g_class *mp, struct g_provider *pp, int flags __unused) g_topology_lock(); root_mount_rel(rht); g_access(cp, -1, 0, 0); - g_part_wither(gp, error); + g_detach(cp); + g_destroy_consumer(cp); + g_destroy_geom(gp); return (NULL); } -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Sat Sep 22 17:13:11 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 27BD4106566B; Sat, 22 Sep 2012 17:13:11 +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 E32BB8FC17; Sat, 22 Sep 2012 17:13:09 +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 UAA07567; Sat, 22 Sep 2012 20:13:08 +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 1TFTGN-000NUn-W4; Sat, 22 Sep 2012 20:13:08 +0300 Message-ID: <505DF1A3.1020809@FreeBSD.org> Date: Sat, 22 Sep 2012 20:13:07 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120913 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: freebsd-geom@FreeBSD.org Subject: 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: Sat, 22 Sep 2012 17:13:11 -0000 Please review the following patch. In addition to what the description says I almost by accident sneaked another change into the patch. It's setting of stripesize to volblocksize. I think that the change should make sense, but it is really a different change. A side note: setting sectorsize to volblocksize seemed like an overkill and it would certainly mess the existing zvols in use. Maybe there should be another property like reportedblocksize or something. commit 1585e6cfb602c2a2647b9f802445bb174bc430a4 Author: Andriy Gapon Date: Wed Sep 19 20:49:28 2012 +0300 zvol: set mediasize in geom provider right upon its creation ... instead of deferring the action until first open. Unlike upstream this has no benefit on FreeBSD. We know that as soon as the provider is created it is going to be tasted and thus opened. Initial mediasize of zero causes tasting failure and subsequent retasting because of the size change. diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c index d47d270..6e9e7a3 100644 --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c @@ -475,6 +475,7 @@ zvol_create_minor(const char *name) zvol_state_t *zv; objset_t *os; dmu_object_info_t doi; + uint64_t volblocksize, volsize; int error; ZFS_LOG(1, "Creating ZVOL %s...", name); @@ -535,9 +536,20 @@ zvol_create_minor(const char *name) zv = zs->zss_data = kmem_zalloc(sizeof (zvol_state_t), KM_SLEEP); #else /* !sun */ + error = zap_lookup(os, ZVOL_ZAP_OBJ, "size", 8, 1, &volsize); + if (error) { + ASSERT(error == 0); + dmu_objset_disown(os, zvol_tag); + mutex_exit(&spa_namespace_lock); + return (error); + } + DROP_GIANT(); g_topology_lock(); zv = zvol_geom_create(name); + zv->zv_volsize = volsize; + zv->zv_provider->mediasize = zv->zv_volsize; + #endif /* !sun */ (void) strlcpy(zv->zv_name, name, MAXPATHLEN); @@ -554,6 +566,7 @@ zvol_create_minor(const char *name) error = dmu_object_info(os, ZVOL_OBJ, &doi); ASSERT(error == 0); zv->zv_volblocksize = doi.doi_data_block_size; + zv->zv_provider->stripesize = zv->zv_volblocksize; if (spa_writeable(dmu_objset_spa(os))) { if (zil_replay_disable) -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Sat Sep 22 17:23:24 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 AD9B7106564A; Sat, 22 Sep 2012 17:23: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 6806A8FC08; Sat, 22 Sep 2012 17:23:23 +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 UAA07621; Sat, 22 Sep 2012 20:23:22 +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 1TFTQH-000NVJ-Tb; Sat, 22 Sep 2012 20:23:21 +0300 Message-ID: <505DF409.9070908@FreeBSD.org> Date: Sat, 22 Sep 2012 20:23:21 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120913 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-geom@FreeBSD.org X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Subject: 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: Sat, 22 Sep 2012 17:23:24 -0000 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 Probably the retasting should be more targeted similarly to what g_retaste does, but in asynchronous mode. This is a missing piece. -- Andriy Gapon