From owner-freebsd-geom@FreeBSD.ORG Thu Jun 17 12:13:46 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92C3716A4CE for ; Thu, 17 Jun 2004 12:13:46 +0000 (GMT) Received: from imap.univie.ac.at (mail.univie.ac.at [131.130.1.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 995F743D55 for ; Thu, 17 Jun 2004 12:13:45 +0000 (GMT) (envelope-from le@FreeBSD.org) Received: from pcle2.cc.univie.ac.at (pcle2.cc.univie.ac.at [131.130.2.177]) by imap.univie.ac.at (8.12.10/8.12.10) with ESMTP id i5HCDB3t1364556; Thu, 17 Jun 2004 14:13:15 +0200 Date: Thu, 17 Jun 2004 14:13:11 +0200 (CEST) From: Lukas Ertl To: Poul-Henning Kamp In-Reply-To: <18115.1087473128@critter.freebsd.dk> Message-ID: <20040617140822.M58154@pcle2.cc.univie.ac.at> References: <18115.1087473128@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-DCC-ZID-Univie-Metrics: imap 4249; Body=2 Fuz1=2 Fuz2=2 cc: geom@FreeBSD.org Subject: Re: GEOM: orphaning open devices X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2004 12:13:46 -0000 On Thu, 17 Jun 2004, Poul-Henning Kamp wrote: > In message <20040617132625.A58154@pcle2.cc.univie.ac.at>, Lukas Ertl writes: >> However, if the fs is mounted and I yank the disk, I don't see an >> orphaning event until the fs is unmounted again, so it seems disk_destroy >> is blocked or rather g_wither_geom waits until the device is closed, which >> makes it rather useless in a production area. > > That is a lot of ground and very little information. Ok, here's a trace of that stuff: Filesystem is mounted, and I yank the disk: ciss1: *** Hot-plug drive removed: SCSI port 1 ID 0 ciss1: *** Physical drive failure: SCSI port 1 ID 0 ciss1: *** State change, logical drive 1 ciss1: logical drive 1 (pass1) changed status OK->failed, spare status 0x0 (da1:ciss1:0:1:0): lost device Then I unmount the filesystem: (da1:ciss1:0:1:0): removing device entry g_post_event_x(0xc04b03c0, 0xc2a2d180, 2, -1068613832) g_post_event_x(0xc04b331c, 0xc2a2db00, 2, -1068613832) ref 0xc2a2db00 g_post_event_x(0xc04b331c, 0xc2774600, 2, -1068613832) ref 0xc2774600 g_post_event_x(0xc04b331c, 0xc2a91100, 2, -1068613832) ref 0xc2a91100 g_post_event_x(0xc04b331c, 0xc2935800, 2, -1068613832) ref 0xc2935800 g_post_event_x(0xc04b331c, 0xc2935d00, 2, -1068613832) ref 0xc2935d00 g_post_event_x(0xc04b331c, 0xc23ec200, 2, -1068613832) ref 0xc23ec200 g_post_event_x(0xc04b331c, 0xc2684100, 2, -1068613832) ref 0xc2684100 g_post_event_x(0xc04b331c, 0xc2684f00, 2, -1068613832) ref 0xc2684f00 g_post_event_x(0xc04b331c, 0xc29f7b80, 2, -1068613832) ref 0xc29f7b80 g_post_event_x(0xc04b331c, 0xc2933780, 2, -1068613832) ref 0xc2933780 g_post_event_x(0xc04b331c, 0xc2a91a80, 2, -1068613832) ref 0xc2a91a80 g_wither_geom(0xc2936b00(da1)) g_orphan_provider(0xc2a2db00(da1), 6) g_orphan_register(da1) g_slice_orphan(0xc28381c0/da1) g_wither_geom(0xc2787a80(da1)) g_orphan_provider(0xc2774600(da1s1), 6) g_detach(0xc28381c0) g_destroy_consumer(0xc28381c0) g_dev_orphan(0xc2a08b40(da1)) g_detach(0xc2a08b40) g_wither_geom(0xc2936b00(da1)) g_destroy_geom(0xc2936b00(da1)) g_destroy_consumer(0xc2a08b40) g_destroy_geom(0xc2a90580(da1)) [...] Hm, on closer look it seems the disk controller/driver doesn't let the drive go. cheers, le -- Lukas Ertl http://homepage.univie.ac.at/l.ertl/ le@FreeBSD.org http://people.freebsd.org/~le/