There are times when ZFS options can not be applied at the moment, i.e. changing desired mountpoints of active filesystems (or setting a mountpoint over a filesystem location that is currently not empty). Such attempts now bail out with messages like: cannot unmount ''/var/adm'': Device busy cannot mount ''/export'': directory is not empty and such. Is it possible to force the new values to be saved into ZFS dataset properties, so they do take effect upon next pool import? I currently work around the harder of such situations with a reboot into a different boot environment or even into a livecd/failsafe, just so that the needed datasets or paths won''t be "busy" and so I can set, verify and apply these mountpoint values. This is not a convenient way to do things :) Thanks, //Jim Klimov
Do you move the pools between machines, or just on the same physical machine? Could you just use symlinks from the new root to the old root so that the names work until you can reboot? It might be more practical to always use symlinks if you do a lot of moving things around, and then you wouldn''t have to figure out how to do the reboot shuffle. Instead, you could just shuffle the symlinks. Gregg Wonderly On Nov 9, 2012, at 10:47 AM, Jim Klimov <jimklimov at cos.ru> wrote:> There are times when ZFS options can not be applied at the moment, > i.e. changing desired mountpoints of active filesystems (or setting > a mountpoint over a filesystem location that is currently not empty). > > Such attempts now bail out with messages like: > cannot unmount ''/var/adm'': Device busy > cannot mount ''/export'': directory is not empty > > and such. > > Is it possible to force the new values to be saved into ZFS dataset > properties, so they do take effect upon next pool import? > > I currently work around the harder of such situations with a reboot > into a different boot environment or even into a livecd/failsafe, > just so that the needed datasets or paths won''t be "busy" and so I > can set, verify and apply these mountpoint values. This is not a > convenient way to do things :) > > Thanks, > //Jim Klimov > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
On 2012-11-09 18:06, Gregg Wonderly wrote: > Do you move the pools between machines, or just on the same physical machine? Could you just use symlinks from the new root to the old root so that the names work until you can reboot? It might be more practical to always use symlinks if you do a lot of moving things around, and then you wouldn''t have to figure out how to do the reboot shuffle. Instead, you could just shuffle the symlinks. No, this concerns datasets within the machine. And symlinks often don''t cut it. For example, I''ve recently needed to switch ''/var'' from an automounted filesystem dataset into a legacy one with the mount from /etc/vfstab. I can''t set the different mountpoint value (legacy) while the OS is up and using the ''var'', and I don''t seem to have a way to do this during reboot automatically (short of crafting an SMF script that would fire early in the boot sequence - but that''s a workaround outside ZFS technology, as is using the livecd or a failsafe boot or another BE). A different example is that sometimes uncareful works with beadm leave the root dataset with a non=''/'' mountpoint attribute. While the proper rootfs is forced to mount at the root node, it is not "clean" to have the discrepancy. However, I can not successfully "zfs set mountpoint=/ rpool/ROOT/bename" while booted into this BE. Forcing the attribute to save the value I need, so it takes effect after reboot - that''s what I am asking for (if that was not clear from my first post). Thanks, //Jim
In general, you can force the unmount with the "-f" flag. As to your specific question of changing the mountpoint to somewhere that it can''t currently be mounted, it should set the mountpoint property but not remount it. E.g.: # zfs set mountpoint=/ rpool/test cannot mount ''/'': directory is not empty property may be set but unable to remount filesystem # zfs get mountpoint rpool/test NAME PROPERTY VALUE SOURCE rpool/test mountpoint / local If for some reason that isn''t working for you, you could try "zfs set canmount=noauto", possibly combined with changing it back to canmount=on after changing the mountpoint. The the zfs(1m) manpage''s description of the canmount property for more details. --matt On Fri, Nov 9, 2012 at 8:47 AM, Jim Klimov <jimklimov at cos.ru> wrote:> There are times when ZFS options can not be applied at the moment, > i.e. changing desired mountpoints of active filesystems (or setting > a mountpoint over a filesystem location that is currently not empty). > > Such attempts now bail out with messages like: > cannot unmount ''/var/adm'': Device busy > cannot mount ''/export'': directory is not empty > > and such. > > Is it possible to force the new values to be saved into ZFS dataset > properties, so they do take effect upon next pool import? > > I currently work around the harder of such situations with a reboot > into a different boot environment or even into a livecd/failsafe, > just so that the needed datasets or paths won''t be "busy" and so I > can set, verify and apply these mountpoint values. This is not a > convenient way to do things :) > > Thanks, > //Jim Klimov > > ______________________________**_________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/**mailman/listinfo/zfs-discuss<http://mail.opensolaris.org/mailman/listinfo/zfs-discuss> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20121112/2a2f1939/attachment.html>