Enda o''Connor - Sun Microsystems Ireland - Software Engineer
2006-Jul-04 15:10 UTC
[zfs-discuss] query re share and zfs
Hi
I was trying to overlay a pool onto an existing mount
# cat /etc/release
Solaris 10 6/06 s10s_u2wos_09a SPARC
........
# df -k /export
Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c1t0d0s3 20174761 3329445 16643569 17% /export
# share
#
#zpool create -f tank raidz c1t1d0 c1t2d0 c1t3d0 c1t4d0 c1t5d0zfs create
tank/home
#zfs create tank/home1
#zfs set mountpoint=/export tank
cannot mount ''/export'': directory is not empty
use legacy mountpoint to allow this behavior, or use the -O flag
#zfs set sharenfs=on tank/home
#zfs set sharenfs=on tank/home1
# share
- /export/home rw ""
- /export/home1 rw ""
#
Now I ran the following to force the mount
# df -k /export
Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c1t0d0s3 20174761 3329445 16643569 17% /export
# zfs mount -O tank
# df -k /export
Filesystem kbytes used avail capacity Mounted on
tank 701890560 53 701890286 1% /export
#
Then further down the line I tried
# zpool destroy tank
cannot unshare ''tank/home'': /export/home: not shared
cannot unshare ''tank/home1'': /export/home1: not shared
could not destroy ''tank'': could not unmount datasets
#
I eventually got this to go with
# zfs umount tank/home
# zfs umount tank/home1
# zpool destroy -f tank
#
Is this normal, and if so why?
Enda
Enda o''Connor - Sun Microsystems Ireland - Software Engineer
2006-Jul-04 15:22 UTC
[zfs-discuss] Re: query re share and zfs
Slight typo I had to run # zfs umount tank cannot unmount ''tank'': not currently mounted # zfs umount /export/home1 # zfs umount /export/home # in order to get zpool destroy to run Enda Enda o''Connor - Sun Microsystems Ireland - Software Engineer wrote:> Hi > I was trying to overlay a pool onto an existing mount > > > > # cat /etc/release > Solaris 10 6/06 s10s_u2wos_09a SPARC > ........ > # df -k /export > Filesystem kbytes used avail capacity Mounted on > /dev/dsk/c1t0d0s3 20174761 3329445 16643569 17% /export > # share > # > #zpool create -f tank raidz c1t1d0 c1t2d0 c1t3d0 c1t4d0 c1t5d0zfs > create tank/home > #zfs create tank/home1 > #zfs set mountpoint=/export tank > cannot mount ''/export'': directory is not empty > use legacy mountpoint to allow this behavior, or use the -O flag > #zfs set sharenfs=on tank/home > #zfs set sharenfs=on tank/home1 > # share > - /export/home rw "" - /export/home1 > rw "" # > > > Now I ran the following to force the mount > > # df -k /export > Filesystem kbytes used avail capacity Mounted on > /dev/dsk/c1t0d0s3 20174761 3329445 16643569 17% /export > # zfs mount -O tank > # df -k /export > Filesystem kbytes used avail capacity Mounted on > tank 701890560 53 701890286 1% /export > # > > Then further down the line I tried > # zpool destroy tank > cannot unshare ''tank/home'': /export/home: not shared > cannot unshare ''tank/home1'': /export/home1: not shared > could not destroy ''tank'': could not unmount datasets > # > > I eventually got this to go with > # zfs umount tank/home > # zfs umount tank/home1 > # zpool destroy -f tank > # > > Is this normal, and if so why? > > > Enda > > > >
Yes, this is a known bug, or rather a clever variation of a known bug. I don''t have the ID handy, but the problem is that ''zfs unmount -a'' (and ''zpool destroy'') both try to unmount filesystems in DSL order, rather than consulting /etc/mnttab. It should just unmount filesystems according to /etc/mnttab. Otherwise, an I/O error in the DSL can render a pool undestroyable. Now in this case, you have mounted a parent container _on top of_ two of its children so that they are no longer visible in the namespace. I''m not sure how the tools would be able to deal with this situation. The problem is that /export/home and /export/home1 appear mounted, but they have been obscured by later mounting /export on top of them (!). I will have to play around with this scenario to see if there''s a way for the utility to know that ''tank'' needs to be unmounted _before_ ''tank/home'' or ''tank/home1''. Casual investigation leads me to believe this is not possible. Despite it sometimes annoyances, the warning about the empty directory is there for a reason. In this case you mounted ''tank'' on top of existing filesystems, totally obscuring them from view. I can try and make the utilities behave a little more sanely in this circumstance, but it doesn''t change the fact that ''/export/home'' was unavailable because of the ''zfs mount -O''. - Eric On Tue, Jul 04, 2006 at 04:10:34PM +0100, Enda o''Connor - Sun Microsystems Ireland - Software Engineer wrote:> Hi > I was trying to overlay a pool onto an existing mount > > > > # cat /etc/release > Solaris 10 6/06 s10s_u2wos_09a SPARC > ........ > # df -k /export > Filesystem kbytes used avail capacity Mounted on > /dev/dsk/c1t0d0s3 20174761 3329445 16643569 17% /export > # share > # > #zpool create -f tank raidz c1t1d0 c1t2d0 c1t3d0 c1t4d0 c1t5d0zfs create > tank/home > #zfs create tank/home1 > #zfs set mountpoint=/export tank > cannot mount ''/export'': directory is not empty > use legacy mountpoint to allow this behavior, or use the -O flag > #zfs set sharenfs=on tank/home > #zfs set sharenfs=on tank/home1 > # share > - /export/home rw "" > - /export/home1 rw "" > # > > > Now I ran the following to force the mount > > # df -k /export > Filesystem kbytes used avail capacity Mounted on > /dev/dsk/c1t0d0s3 20174761 3329445 16643569 17% /export > # zfs mount -O tank > # df -k /export > Filesystem kbytes used avail capacity Mounted on > tank 701890560 53 701890286 1% /export > # > > Then further down the line I tried > # zpool destroy tank > cannot unshare ''tank/home'': /export/home: not shared > cannot unshare ''tank/home1'': /export/home1: not shared > could not destroy ''tank'': could not unmount datasets > # > > I eventually got this to go with > # zfs umount tank/home > # zfs umount tank/home1 > # zpool destroy -f tank > # > > Is this normal, and if so why? > > > Enda > > > > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss-- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
Enda o''Connor - Sun Microsystems Ireland - Software Engineer
2006-Jul-05 12:46 UTC
[zfs-discuss] query re share and zfs
Hi Eric Thanks for the update. Basically I am just trying to have tank mounted onto /export and I''m not concerned about what is already in /export, I''m just doing some zfs testing as part of ongoing patch release, and trying to script a quick and dirty way of making /export a zfs pool without having to reboot etc. So personally I am not too concerned about the warning re empty directory, I know what it is and I forced the mount so as to get tank onto /export. As part of the script I destroy the pool as well, to do that currently I just get the mountpoints and then zfs umount starting at the parent which does the trick as you explained. So at this point I have just sharenfs=on for tank, so that home and home1 will be shared by default. I wasn''t aware that zfs create was also doing a mount, which were being covered over by explicit my mount -o after the zfs create I''ve reversed the order so that the mount -o goes in first before the subsequent zfs creates. thanks Enda Eric Schrock wrote:>Yes, this is a known bug, or rather a clever variation of a known bug. >I don''t have the ID handy, but the problem is that ''zfs unmount -a'' (and >''zpool destroy'') both try to unmount filesystems in DSL order, rather >than consulting /etc/mnttab. It should just unmount filesystems >according to /etc/mnttab. Otherwise, an I/O error in the DSL can render >a pool undestroyable. > >Now in this case, you have mounted a parent container _on top of_ two of >its children so that they are no longer visible in the namespace. I''m >not sure how the tools would be able to deal with this situation. The >problem is that /export/home and /export/home1 appear mounted, but they >have been obscured by later mounting /export on top of them (!). I will >have to play around with this scenario to see if there''s a way for the >utility to know that ''tank'' needs to be unmounted _before_ ''tank/home'' >or ''tank/home1''. Casual investigation leads me to believe this is not >possible. > >Despite it sometimes annoyances, the warning about the empty directory >is there for a reason. In this case you mounted ''tank'' on top of >existing filesystems, totally obscuring them from view. I can try and >make the utilities behave a little more sanely in this circumstance, but >it doesn''t change the fact that ''/export/home'' was unavailable because >of the ''zfs mount -O''. > >- Eric > >On Tue, Jul 04, 2006 at 04:10:34PM +0100, Enda o''Connor - Sun Microsystems Ireland - Software Engineer wrote: > > >>Hi >>I was trying to overlay a pool onto an existing mount >> >> >> >># cat /etc/release >> Solaris 10 6/06 s10s_u2wos_09a SPARC >> ........ >># df -k /export >>Filesystem kbytes used avail capacity Mounted on >>/dev/dsk/c1t0d0s3 20174761 3329445 16643569 17% /export >># share >># >>#zpool create -f tank raidz c1t1d0 c1t2d0 c1t3d0 c1t4d0 c1t5d0zfs create >>tank/home >>#zfs create tank/home1 >>#zfs set mountpoint=/export tank >>cannot mount ''/export'': directory is not empty >>use legacy mountpoint to allow this behavior, or use the -O flag >>#zfs set sharenfs=on tank/home >>#zfs set sharenfs=on tank/home1 >># share >>- /export/home rw "" >>- /export/home1 rw "" >># >> >> >>Now I ran the following to force the mount >> >># df -k /export >>Filesystem kbytes used avail capacity Mounted on >>/dev/dsk/c1t0d0s3 20174761 3329445 16643569 17% /export >># zfs mount -O tank >># df -k /export >>Filesystem kbytes used avail capacity Mounted on >>tank 701890560 53 701890286 1% /export >># >> >>Then further down the line I tried >># zpool destroy tank >>cannot unshare ''tank/home'': /export/home: not shared >>cannot unshare ''tank/home1'': /export/home1: not shared >>could not destroy ''tank'': could not unmount datasets >># >> >>I eventually got this to go with >># zfs umount tank/home >># zfs umount tank/home1 >># zpool destroy -f tank >># >> >>Is this normal, and if so why? >> >> >>Enda >> >> >> >> >>_______________________________________________ >>zfs-discuss mailing list >>zfs-discuss at opensolaris.org >>http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >> >> > >-- >Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20060705/bf320a09/attachment.html>
On 7/5/06, Enda o''Connor - Sun Microsystems Ireland - Software Engineer <Enda.Oconnor at sun.com> wrote:> > Hi Eric > Thanks for the update. > Basically I am just trying to have tank mounted onto /export and I''m not > concerned about what is already in /export, > I''m just doing some zfs testing as part of ongoing patch release, and > trying to script a quick and dirty way of making /export a zfs pool without > having to reboot etc. So personally I am not too concerned about the warning > re empty directory, I know what it is and I forced the mount so as to get > tank onto /export.zfs set mountpoint=/export tank should work James Dickens uadmin.blogspot.com> As part of the script I destroy the pool as well, to do that currently I > just get the mountpoints and then zfs umount starting at the parent which > does the trick as you explained. > > So at this point I have just sharenfs=on for tank, so that home and home1 > will be shared by default. > I wasn''t aware that zfs create was also doing a mount, which were being > covered over by explicit my mount -o after the zfs create > I''ve reversed the order so that the mount -o goes in first before the > subsequent zfs creates. > > thanks > Enda > > > > > > Eric Schrock wrote: > > Yes, this is a known bug, or rather a clever variation of a known bug. > I don''t have the ID handy, but the problem is that ''zfs unmount -a'' (and > ''zpool destroy'') both try to unmount filesystems in DSL order, rather > than consulting /etc/mnttab. It should just unmount filesystems > according to /etc/mnttab. Otherwise, an I/O error in the DSL can render > a pool undestroyable. > > Now in this case, you have mounted a parent container _on top of_ two of > its children so that they are no longer visible in the namespace. I''m > not sure how the tools would be able to deal with this situation. The > problem is that /export/home and /export/home1 appear mounted, but they > have been obscured by later mounting /export on top of them (!). I will > have to play around with this scenario to see if there''s a way for the > utility to know that ''tank'' needs to be unmounted _before_ ''tank/home'' > or ''tank/home1''. Casual investigation leads me to believe this is not > possible. > > Despite it sometimes annoyances, the warning about the empty directory > is there for a reason. In this case you mounted ''tank'' on top of > existing filesystems, totally obscuring them from view. I can try and > make the utilities behave a little more sanely in this circumstance, but > it doesn''t change the fact that ''/export/home'' was unavailable because > of the ''zfs mount -O''. > > - Eric > > On Tue, Jul 04, 2006 at 04:10:34PM +0100, Enda o''Connor - Sun Microsystems > Ireland - Software Engineer wrote: > > > Hi > I was trying to overlay a pool onto an existing mount > > > > # cat /etc/release > Solaris 10 6/06 s10s_u2wos_09a SPARC > ........ > # df -k /export > Filesystem kbytes used avail capacity Mounted on > /dev/dsk/c1t0d0s3 20174761 3329445 16643569 17% /export > # share > # > #zpool create -f tank raidz c1t1d0 c1t2d0 c1t3d0 c1t4d0 c1t5d0zfs create > tank/home > #zfs create tank/home1 > #zfs set mountpoint=/export tank > cannot mount ''/export'': directory is not empty > use legacy mountpoint to allow this behavior, or use the -O flag > #zfs set sharenfs=on tank/home > #zfs set sharenfs=on tank/home1 > # share > - /export/home rw "" > - /export/home1 rw "" > # > > > Now I ran the following to force the mount > > # df -k /export > Filesystem kbytes used avail capacity Mounted on > /dev/dsk/c1t0d0s3 20174761 3329445 16643569 17% /export > # zfs mount -O tank > # df -k /export > Filesystem kbytes used avail capacity Mounted on > tank 701890560 53 701890286 1% /export > # > > Then further down the line I tried > # zpool destroy tank > cannot unshare ''tank/home'': /export/home: not shared > cannot unshare ''tank/home1'': /export/home1: not shared > could not destroy ''tank'': could not unmount datasets > # > > I eventually got this to go with > # zfs umount tank/home > # zfs umount tank/home1 > # zpool destroy -f tank > # > > Is this normal, and if so why? > > > Enda > > > > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > > -- > Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock > > > > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > > >