From owner-freebsd-bugs@FreeBSD.ORG Mon Oct 12 21:00:13 2009 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A486B106568B for ; Mon, 12 Oct 2009 21:00:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 80D718FC1B for ; Mon, 12 Oct 2009 21:00:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n9CL06jB064797 for ; Mon, 12 Oct 2009 21:00:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n9CL065g064796; Mon, 12 Oct 2009 21:00:06 GMT (envelope-from gnats) Resent-Date: Mon, 12 Oct 2009 21:00:06 GMT Resent-Message-Id: <200910122100.n9CL065g064796@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Dirk-Willem van Gulik Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FC03106568B for ; Mon, 12 Oct 2009 20:50:16 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 7E8FF8FC1C for ; Mon, 12 Oct 2009 20:50:16 +0000 (UTC) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n9CKoF8x028870 for ; Mon, 12 Oct 2009 20:50:15 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id n9CKoFxv028869; Mon, 12 Oct 2009 20:50:15 GMT (envelope-from nobody) Message-Id: <200910122050.n9CKoFxv028869@www.freebsd.org> Date: Mon, 12 Oct 2009 20:50:15 GMT From: Dirk-Willem van Gulik To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: kern/139549: reconnecting a firewire disk does not cause the disklabel to update correctly/invalidate the cache X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 21:00:13 -0000 >Number: 139549 >Category: kern >Synopsis: reconnecting a firewire disk does not cause the disklabel to update correctly/invalidate the cache >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Oct 12 21:00:06 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Dirk-Willem van Gulik >Release: 7.2-Release >Organization: Private Individual >Environment: FreeBSD 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Sun Oct 11 14:20:49 CEST 2009 root@:/usr/src/sys/i386/compile/GENERIC i386 >Description: Connecting a different firewire disk whilst _not_ changing the enclosure does not cause the disklabel to be updated correctly. I.e. some older cached entry is seen. >How-To-Repeat: Required - machine with 7.2 - ONE firewire enclosure - two disks which can be plugged into above enclosure; one at the time, To reproduce: 0) Create two formatted IDE disk; e.g. one with a single s1c partition covering the whole disk and the other with a few s1a, s1d or similar - i.e. a default freebsd install. 1) Install 7.2 as-is. 2) Wire the first disk into the enclosure; and plug it into firewire. 3) Usual dmesg/camcontrol status will show it is there. 4) Check you can mount something like 'mount /dev/da4s1c' as expected. 5) Now unplug the firewire; and swap the second disk into the enclosure. 6) Plug in the firewire - and observe dmesg to pick it up. HOWEVER notice that the /dev/da4*** entry is still the same - it has not updated for the fact that disk 2 contained a a, d, e and f partition. >Fix: Sometimes (though not always) a 'disklabel -e' followed by a write of the label will cause the /dev/ devices to update. However this only seems to be the case for some labels - NTFS, FAT and various linux partitions do not seem to be that easily 'seen'. >Release-Note: >Audit-Trail: >Unformatted: