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. 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'. 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.
Responsible Changed From-To: freebsd-bugs->freebsd-firewire Over to maintainer(s).
pre-8.0 has a default of "3" set to the sysctl "firewire.hold_count" or some such thing that keeps the disconnect/removal of a firewire device from doing "things". Try setting that value to "1" and see if the problem manifests itself. Sean
Sean wrote: > pre-8.0 has a default of "3" set to the sysctl "firewire.hold_count" or > some such thing that keeps the disconnect/removal of a firewire device > from doing "things". > > Try setting that value to "1" and see if the problem manifests itself. Regardless of the setting - it seems that the disklabel continues to be cached - and thus no updating of the /dev's (e.g. matching the actual slices/partitions) happens. I guess that we need a firewire.force_update_on_reconnect which completley wacks any disklabel/da -or- perhaps abandons trying to use the lowest number possible; but keeps on counting it as a higher one. Thanks, Dw http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this.
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped