summaryrefslogtreecommitdiffstats
path: root/cmd/zpool
diff options
context:
space:
mode:
authorBrian Behlendorf <[email protected]>2010-12-16 16:16:25 -0800
committerBrian Behlendorf <[email protected]>2011-02-04 16:11:58 -0800
commit3fb1fcdea167d705e050a0383ec61b95fbe8a0ed (patch)
treefb51bf57eeb08ff51c49ae7aae36c10575a780a5 /cmd/zpool
parentfeb46b92a7619a3bb67b925e24184fe70464d261 (diff)
Add 'zfs mount' support
By design the zfs utility is supposed to handle mounting and unmounting a zfs filesystem. We could allow zfs to do this directly. There are system calls available to mount/umount a filesystem. And there are library calls available to manipulate /etc/mtab. But there are a couple very good reasons not to take this appraoch... for now. Instead of directly calling the system and library calls to (u)mount the filesystem we fork and exec a (u)mount process. The principle reason for this is to delegate the responsibility for locking and updating /etc/mtab to (u)mount(8). This ensures maximum portability and ensures the right locking scheme for your version of (u)mount will be used. If we didn't do this we would have to resort to an autoconf test to determine what locking mechanism is used. The downside to using mount(8) instead of mount(2) is that we lose the exact errno which was returned by the kernel. The return code from mount(8) provides some insight in to what went wrong but it not quite as good. For the moment this is translated as a best guess in to a errno for the higher layers of zfs. In the long term a shared library called libmount is under development which provides a common API to address the locking and errno issues. Once the standard mount utility has been updated to use this library we can then leverage it. Until then this is the only safe solution. http://www.kernel.org/pub/linux/utils/util-linux/libmount-docs/index.html
Diffstat (limited to 'cmd/zpool')
0 files changed, 0 insertions, 0 deletions