src/lib, branch zfs-0.6.2

No point in rewind() mtab in zfs_unshare_proto(). We're not really

2013-08-15T17:18:31Z

reading the file, but instead use libzfs_mnttab_find() which does the nessesary freopen() for us. Signed-off-by: Brian Behlendorf Issue #1498

Fix for re-reading /etc/mtab in zfs_is_mounted()

2013-08-14T18:37:06Z

When /etc/mtab is updated on Linux it's done atomically with rename(2). A new mtab is written, the existing mtab is unlinked, and the new mtab is renamed to /etc/mtab. This means that we must close the old file and open the new file to get the updated contents. Using rewind(3) will just move the file pointer back to the start of the file, freopen(3) will close and open the file. Signed-off-by: Brian Behlendorf Closes #1611

Illumos #3098 zfs userspace/groupspace fail

2013-08-14T16:28:34Z

3098 zfs userspace/groupspace fail without saying why when run as non-root Reviewed by: Eric Schrock Approved by: Richard Lowe References: https://www.illumos.org/issues/3098 illumos/illumos-gate@70f56fa69343b013f47e010537cff8ef3a7a40a5 Ported-by: Tim Chase Signed-off-by: Brian Behlendorf Closes #1596

Fix zpool_read_label()

2013-07-09T23:02:04Z

The zpool_read_label() function was subtly broken due to a difference of behavior in fstat64(2) on Solaris vs Linux. Under Solaris when a block device is stat'ed the st_size field will contain the size of the device in bytes. Under Linux this is only true for regular file and symlinks. A compatibility function called fstat64_blk(2) was added which can be used when the Solaris behavior is required. This flaw was never noticed because the only time we would need to use the device size is when the first two labels are damaged. I noticed this issue while adding the zpool_clear_label() function which is similar in design and does require us to write all the labels. Signed-off-by: Brian Behlendorf

Add FreeBSD 'zpool labelclear' command

2013-07-09T22:58:05Z

The FreeBSD implementation of zfs adds the 'zpool labelclear' command. Since this functionality is helpful and straight forward to add it is being included in ZoL. References: freebsd/freebsd@119a041dc9230275239a8de68c534c0754181e7e Ported-by: Dmitry Khasanov Signed-off-by: Brian Behlendorf Closes #1126

Readd zpool_clear_label() from OpenSolaris

2013-07-09T22:42:27Z

This patch restores the zpool_clear_label() function from OpenSolaris. This was removed by commit d603ed6 because it wasn't clear we had a use for it in ZoL. However, this functionality is a prerequisite for adding the 'zpool labelclear' command from FreeBSD. As part of bringing this change in the zpool_clear_label() function was changed to use fstat64_blk(2) for compatibility with Linux. Signed-off-by: Brian Behlendorf Issue #1126

Add error message for missing /etc/mtab

2013-06-27T21:43:37Z

The zpool command should not silently fail when the /etc/mtab file does not exist. This can occur in an initramfs environment when the /etc/mtab file hasn't yet been generated. Signed-off-by: Brian Behlendorf Closes #1541

Illumos #3006

2013-06-19T22:14:10Z

3006 VERIFY[S,U,P] and ASSERT[S,U,P] frequently check if first argument is zero Reviewed by Matt Ahrens Reviewed by George Wilson Approved by Eric Schrock References: illumos/illumos-gate@fb09f5aad449c97fe309678f3f604982b563a96f https://illumos.org/issues/3006 Requires: zfsonlinux/spl@1c6d149feb4033e4a56fb987004edc5d45288bcb Ported-by: Tim Chase Signed-off-by: Brian Behlendorf Closes #1509

Don't leak mount flags into kernel

2013-06-18T22:30:08Z

When calling mount(), care must be taken to avoid passing in flags that are used only by the user space utilities. Otherwise we may stomp on flags that are reserved for other purposes in the kernel. In particular, openSUSE 12.3 kernels have added a new MS_RICHACL super-block flag whose value conflicts with our MS_COMMENT flag. This causes incorrect behavior such as the umask being ignored. The MS_COMMENT flag essentially serves as a placeholder in the option_map data structure of zfs_mount.c, but its value is never used. Therefore we can avoid the conflict by defining it to 0. The MS_USERS, MS_OWNER, and MS_GROUP flags also conflict with reserved flags in the kernel. While this is not known to have caused any problems, it is nevertheless incorrect. For the purposes of the mount.zfs helper, the "users", "owner", and "group" options just serve as hints to set additional implied options. Therefore we now define their associated mount flags in terms of the options that they imply rather than giving them unique values. Signed-off-by: Brian Behlendorf Closes #1457

Use taskq for dump_bytes()

2013-05-06T21:05:42Z

The vn_rdwr() function performs I/O by calling the vfs_write() or vfs_read() functions. These functions reside just below the system call layer and the expectation is they have almost the entire 8k of stack space to work with. In fact, certain layered configurations such as ext+lvm+md+multipath require the majority of this stack to avoid stack overflows. To avoid this posibility the vn_rdwr() call in dump_bytes() has been moved to the ZIO_TYPE_FREE, taskq. This ensures that all I/O will be performed with the majority of the stack space available. This ends up being very similiar to as if the I/O were issued via sys_write() or sys_read(). Signed-off-by: Brian Behlendorf Closes #1399 Closes #1423