For the record, this happened with a new filesystem. I didn't muck about with an old filesystem while it was still mounted, I created a new one, mounted it and then accidentally exported it.
> > Except that it doesn't: > > > > # mount /dev/dsk/c1t1d0s0 /mnt > > # share /mnt > > # umount /mnt > > umount: /mnt busy > > # unshare /mnt > > # umount /mnt > > If you umount -f it will though! Well, sure, but I was still surprised that it happened anyway. > The system is working as designed, the NFS client did > what it was supposed to do. If you brought the pool back in > again with zpool import things should have picked up where they left off. Yep -- an import/shareall made the FS available again. > Whats more you we probably running as root when you > did that so you got what you asked for - there is only so much protection > we can give without being annoying! Sure, but there are still safeguards in place even when running things as root, such as requiring "umount -f" as above, or warning you when running format on a disk with mounted partitions. Since this appeared to be an operation that may warrant such a safeguard I thought I'd check and see if this was to be expected or if a safeguard should be put in. Annoying isn't always bad :-> > Now having said that I personally wouldn't have > expected that zpool export should have worked as easily as that while > there where shared filesystems. I would have expected that exporting > the pool should have attempted to unmount all the ZFS filesystems first - > which would have failed without a -f flag because they were shared. > > So IMO it is a bug or at least an RFE. Ok, where should I file an RFE? Jim This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
