Date: Tue, 19 Sep 2006 10:05:16 -0500 From: "M. L. Dodson" <mldodson@houston.rr.com> To: freebsd-firewire@FreeBSD.org Subject: devfs and hot unplugging firewire device Message-ID: <200609191005.17015.mldodson@houston.rr.com>
next in thread | raw e-mail | index | archive | help
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 <options>" 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200609191005.17015.mldodson>