From owner-freebsd-firewire@FreeBSD.ORG Tue Sep 19 17:51:39 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 4AF3A16A40F for ; Tue, 19 Sep 2006 17:51:39 +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 98F3643D73 for ; Tue, 19 Sep 2006 17:51:38 +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 k8JHpaHo023669; Tue, 19 Sep 2006 12:51:37 -0500 (CDT) Received: from localhost (localhost [[UNIX: localhost]]) by localhost.houston.rr.com (8.13.8/8.13.6/Submit) id k8JHpZDx001002; Tue, 19 Sep 2006 12:51:35 -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: John-Mark Gurney Date: Tue, 19 Sep 2006 12:51:35 -0500 User-Agent: KMail/1.9.4 References: <200609191005.17015.mldodson@houston.rr.com> <200609191125.35128.mldodson@houston.rr.com> <20060919171950.GD23915@funkthat.com> In-Reply-To: <20060919171950.GD23915@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609191251.35787.mldodson@houston.rr.com> X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: freebsd-firewire@freebsd.org Subject: Re: 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 17:51:39 -0000 On Tuesday 19 September 2006 12:19, John-Mark Gurney wrote: > M. L. Dodson wrote this message on Tue, Sep 19, 2006 at 11:25 -0500: > > On Tuesday 19 September 2006 11:04, John-Mark Gurney wrote: > > > M. L. Dodson wrote this message on Tue, Sep 19, 2006 at 10:05 -0500: > > > > When I finished a dump/restore, I just pulled the cable (the > > > > firewire disk partitions were not mounted). When I plugged in the > > > > > > The problem is that the old devices still are open for writing.. If > > > you were to umount -f the old fs, most likely, the devices would > > > wither away, and things would be back to normal... > > > > Hmmm... I just looked at the umount man page. I guess the > > behaviour you describe can be implied by it, but it is certainly > > not obvious (at least to me). So, if I understand you, if instead > > of "umount /mnt", I do "umount -f /mnt", the behaviour will be as > > I expected: the device will be completely unmounted and the device > > will disappear when I pull the cable? > > The -f is only necessary if you've already removed the drive... You > should be able to do a normal umount /mnt before you pull the drive > and then everything will just work... > Then something is still not right. I always did a umount before I pulled the cable. Never did I pull the cable on a mounted drive (if I had, I would have expected a kernel panic). So I'm still confused. It is true that the device (when mounted for the rsync tests) was mounted r/w, and that was a mistake on my part. But if I'm following this dialog correctly, I should not have had devices such as /dev/da0s1a, b, c, d, e, f, and g survive more than a short interval after pulling the cable. But they did, and when I plugged another disk in I got /dev/da0s1a, /dev/da0s1aa, /dev/da0s1ab, /dev/da0s1ac, /dev/da0s1ad, /dev/da0s1ae, /dev/da0s1af, /dev/da0s1ag, /dev/da0s1b, /dev/da0s1c, /dev/da0s1d, /dev/da0s1e, /dev/da0s1f, and /dev/da0s1g. I did not try to fsck /dev/da0s1a? (that would have been just too funky), but fsck /dev/da0s1a and fsck /dev/da0s1g worked; devices /dev/da0s1d, /dev/da0s1e, and /dev/da0s1f failed fsck with the error message that the superblock could not found. Does this tell you anything new? > > > I hope you were fsync'ing the files before you unmounted the disk > > > to ensure that the file was completely written to disk, otherwise > > > you could end up w/ the an incomplete file... > > > > Actually, my sequence was: fsck the /dev/da0s1* (excluding b and > > c), and that was where I noticed the problem (on the second > > firewire disk in the sequence of 7 disks dumped), then dump the g > > partition to a file on the server's main disk. Then I did a > > restore -if in the directory I wanted the stuff > > to go into. I did it this way so I could exclude some unimportant > > stuff that was in the /home directory on the firewire disk > > (corresponding to /dev/da0s1g). The only time I mounted the disk > > was to rsync between the firewire /home (/dev/da0s1g) and the > > restored data directory to check for errors. (This data cost > > weeks of computation for many of the files, so better to take a > > little time to wear belt AND suspenders). The firewire disk was > > only ever read from, not written to except for the fsck. Your > > answer implies to me that if I had never mounted the device it > > would have gone away when I pulled the cable. Right? > > Correct... > > > > > 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? > > > > > > umount the file system... I unplug firewire drives that don't have > > > mounted filesystems, and haven't had an issue with it... > > > > OK, that is certainly what I get from your first couple of > > paragraphs. Thanks for the explanation! > > np... -- M. L. Dodson Email: mldodson-at-houston-dot-rr-dot-com Phone: eight_three_two-56_three-386_one