From owner-freebsd-firewire@FreeBSD.ORG Tue Sep 19 15:14:07 2006 Return-Path: X-Original-To: freebsd-firewire@FreeBSD.org Delivered-To: freebsd-firewire@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2667E16A558 for ; Tue, 19 Sep 2006 15:14:07 +0000 (UTC) (envelope-from mldodson@houston.rr.com) Received: from ms-smtp-01.texas.rr.com (ms-smtp-01.texas.rr.com [24.93.47.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C4F743FB3 for ; Tue, 19 Sep 2006 15:05:19 +0000 (GMT) (envelope-from mldodson@houston.rr.com) Received: from localhost.houston.rr.com (cpe-24-167-77-130.houston.res.rr.com [24.167.77.130]) by ms-smtp-01.texas.rr.com (8.13.6/8.13.6) with ESMTP id k8JF5HQc010721 for ; Tue, 19 Sep 2006 10:05:18 -0500 (CDT) Received: from localhost (localhost [[UNIX: localhost]]) by localhost.houston.rr.com (8.13.6/8.13.6/Submit) id k8JF5HMB053435 for freebsd-firewire@FreeBSD.org; Tue, 19 Sep 2006 10:05:17 -0500 (CDT) (envelope-from mldodson@houston.rr.com) X-Authentication-Warning: localhost.houston.rr.com: bdodson set sender to mldodson@houston.rr.com using -f From: "M. L. Dodson" To: freebsd-firewire@FreeBSD.org Date: Tue, 19 Sep 2006 10:05:16 -0500 User-Agent: KMail/1.9.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609191005.17015.mldodson@houston.rr.com> X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: Subject: devfs and hot unplugging firewire device X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mldodson@houston.rr.com List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2006 15:14:07 -0000 I posted this to questions@ last week but got no response, so thought I would try this list since the specific instance involved firewire. I suspect this is a behaviour that might be modulated by some devfs rules, but I can't figure them out, and there does not appear to be a list that focuses on devfs. In any case: I was transferring a bunch of data files from compute node disks to a server using dump-restore. This before I put the disks in storage for a few months. I put the disks with the data files into an external firewire device, plugged it in, and did the transfers. All the dump/restores worked (eventually), but I had to reboot the server between every disk's dump/restore combination (see below). This is on 6.1-RELEASE-p6. When I finished a dump/restore, I just pulled the cable (the firewire disk partitions were not mounted). When I plugged in the next drive, devfs created devices with names like /dev/da0s1aa, /dev/da0s1ab, /dev/da0s1ac, etc., in addition to the regular /dev/da0s1a, etc (which were left over from the first disk, they were not destroyed when I pulled the cable). When I tried to fsck the firewire disk partitions after this behaviour, /dev/da0s1a and /dev/da0s1g worked fine (as did the dump/restore from /dev/da0s1g). The other partitions, /dev/da0s1d, e, and f, failed, saying the superblock could not be found. Only a reboot gave a system with all /dev/da0s1* reflecting the actual firewire disk partitions after a hot plugin. All the data disks that were dumped were of the same kind and had identical partitioning schemes. My question: Should I be doing something to signal devfs I'm going to unplug a device so it won't get confused when I plug in another similar, but not the same, device? camcontrol commands like "camcontrol eject " and "camcontrol rescan all" seemed to not have the results I expected. What's going on here? Bud Dodson -- M. L. Dodson Email: mldodson-at-houston-dot-rr-dot-com Phone: eight_three_two-56_three-386_one