[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
devfs and hot unplugging firewire device
- To: freebsd-firewire_(_at_)_FreeBSD_(_dot_)_org
- Subject: devfs and hot unplugging firewire device
- From: "M. L. Dodson" <mldodson_(_at_)_houston_(_dot_)_rr_(_dot_)_com>
- Date: Tue, 19 Sep 2006 10:05:16 -0500
- Cc:
- Reply-to: mldodson_(_at_)_houston_(_dot_)_rr_(_dot_)_com
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
_______________________________________________
freebsd-firewire_(_at_)_freebsd_(_dot_)_org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "freebsd-firewire-unsubscribe_(_at_)_freebsd_(_dot_)_org"
Visit your host, monkey.org