devfs and hot unplugging firewire device
M. L. Dodson
mldodson at houston.rr.com
Tue Sep 19 10:51:39 PDT 2006
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
> > > 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 <dumped to file> 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?
> > > > 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?
> > >
> > > 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!
M. L. Dodson
More information about the freebsd-firewire