|
|
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@xxxxxxxxxxxxxxx
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
|
|