From owner-cvs-src@FreeBSD.ORG Fri Nov 18 18:09:14 2005 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 246F816A41F; Fri, 18 Nov 2005 18:09:14 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9003843D76; Fri, 18 Nov 2005 18:09:13 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [64.81.189.67]) by blake.polstra.com (8.13.1/8.13.1) with ESMTP id jAII9CRT041951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Nov 2005 10:09:12 -0800 (PST) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.13.1/8.13.1/Submit) id jAII99QB049758; Fri, 18 Nov 2005 10:09:09 -0800 (PST) (envelope-from jdp) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <437DFA34.8040308@samsco.org> Date: Fri, 18 Nov 2005 10:09:09 -0800 (PST) From: John Polstra To: Scott Long Cc: cvs-src@FreeBSD.org, Poul-Henning Kamp , src-committers@FreeBSD.org, Lukas Ertl , cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/cam/scsi scsi_cd.c scsi_da.c src/sys/geom geom_disk.c geom_disk.h geom_subr.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2005 18:09:14 -0000 On 18-Nov-2005 Scott Long wrote: > Poul-Henning Kamp wrote: >> In message <437DEEE5.9040201@samsco.org>, Scott Long writes: >> >>>Poul-Henning Kamp wrote: >> >> >>>>Most drivers seem to detach their internal state from the struct >>>>disk, and therefore they don't need this. >>>> >>> >>>So what makes CAM special in this regard? >> >> >> I dunno. Cam seems to have a different lifecycle for devices >> but I have never dived deep enough to figure it out. >> > > Ok. John's fix seems hackish (no offense John). I'll likely look at > this in the coming months. No offense taken, Scott. :-) I think what makes CAM special is that it reference counts all of its data structures, so they don't go away until the last close of the device even though the drive itself is long gone. In particular, dacleanup() isn't called until the last close, and it's what calls disk_destroy(). Geom needs to know when the physical drive is gone, not when CAM decides it can free its associated data structures. The disk_gone() idea was suggested by PHK, and it seems reasonable to me. But I've still got a lot to learn about both CAM and geom, so if you can come up with something better, then that would be great. John