diff options
author | Brian Behlendorf <[email protected]> | 2010-12-16 16:16:25 -0800 |
---|---|---|
committer | Brian Behlendorf <[email protected]> | 2011-02-04 16:11:58 -0800 |
commit | 3fb1fcdea167d705e050a0383ec61b95fbe8a0ed (patch) | |
tree | fb51bf57eeb08ff51c49ae7aae36c10575a780a5 /scripts/zpool-layout | |
parent | feb46b92a7619a3bb67b925e24184fe70464d261 (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 'scripts/zpool-layout')
0 files changed, 0 insertions, 0 deletions