]> granicus.if.org Git - zfs/log
zfs
11 years agoIllumos #1884, #3028, #3048, #3049, #3060, #3061, #3093
Yuri Pankov [Thu, 10 Jan 2013 22:25:47 +0000 (14:25 -0800)]
Illumos #1884, #3028, #3048, #3049, #3060, #3061, #3093

1884 Empty "used" field for zfs *space commands
3028 zfs {group,user}space -n prints (null) instead of numeric GID/UID
3048 zfs {user,group}space [-s|-S] is broken
3049 zfs {user,group}space -t doesn't really filter the results
3060 zfs {user,group}space -H output isn't tab-delimited
3061 zfs {user,group}space -o doesn't use specified fields order
3093 zfs {user,group}space's -i is noop

Reviewed by: Garry Mills <gary_mills@fastmail.fm>
Reviewed by: Eric Schrock <eric.schrock@delphix.com>
Approved by: Richard Lowe <richlowe@richlowe.net>

References:
  illumos/illumos-gate@89f5d17b06fc4132c983112b24836a779a0ed736
  illumos changeset: 13803:b5e49d71ff0e
  https://www.illumos.org/issues/1884
  https://www.illumos.org/issues/3028
  https://www.illumos.org/issues/3048
  https://www.illumos.org/issues/3049
  https://www.illumos.org/issues/3060
  https://www.illumos.org/issues/3061
  https://www.illumos.org/issues/3093

Ported-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1194

11 years agoIllumos #1377 `zpool status -D' should tell if there are no DDT entries
Yuri Pankov [Fri, 11 Jan 2013 17:11:09 +0000 (09:11 -0800)]
Illumos #1377 `zpool status -D' should tell if there are no DDT entries

1337 `zpool status -D' should tell if there are no DDT entries

Reviewed by: Eric Schrock <eric.schrock@delphix.com>
Reviewed by: Igor Kozhukhov <ikozhukhov@gmail.com>
Reviewed by: George Wilson <gwilson@zfsmail.com>
Approved by: Albert Lee <trisk@nexenta.com>

References:
  illumos/illumos-gate@ce72e614c133351311e87bbbe4eba8fea9e77768
  illumos changeset: 13432:d1ad8d106d64
  https://www.illumos.org/issues/1337

Ported-by: Brian Behlendorf <behlendorf1@llnl.gov>
11 years agoIllumos #1557 assertion failed in userland taskq_destroy()
Garrett D'Amore [Fri, 11 Jan 2013 17:04:23 +0000 (09:04 -0800)]
Illumos #1557 assertion failed in userland taskq_destroy()

1557 assertion failed in userland taskq_destroy()

Reviewed by: Richard Lowe <richlowe@richlowe.net>
Reviewed by: George Wilson <gwilson@zfsmail.com>
Approved by: Eric Schrock <eric.schrock@delphix.com>

References:
  illumos/illumos-gate@aa846ad9bc4785806bb6263657698d5890afbc08
  illumos changeset: 13597:3eac1e8e0f4c
  https://www.illumos.org/issues/1557

Ported-by: Brian Behlendorf <behlendorf1@llnl.gov>
11 years agoIllumos #2618 arc.c mistypes in the comments
Bart Coddens [Fri, 11 Jan 2013 16:54:18 +0000 (08:54 -0800)]
Illumos #2618 arc.c mistypes in the comments

2618 arc.c mistypes in the comments

Reviewed by: Jason King <jason.brian.king@gmail.com>
Reviewed by: Josef Sipek <jeffpc@josefsipek.net>
Approved by: Richard Lowe <richlowe@richlowe.net>

References:
  illumos/illumos-gate@fc98fea58e89224f6f13d7fae246d6cb5dfa35ea
  illumos changeset: 13721:5b51a16a186f
  https://www.illumos.org/issues/2618

Ported-by: Brian Behlendorf <behlendorf1@llnl.gov>
11 years agoOnly use gcc -Wunused-but-set-variable when available
Brian Behlendorf [Fri, 11 Jan 2013 00:09:31 +0000 (16:09 -0800)]
Only use gcc -Wunused-but-set-variable when available

Certain versions of gcc generate an 'unrecognized command
line option' error message when -Wunused-but-set-variable
is used unconditionally.  This in turn can cause several
of the autoconf tests to misdetect an interface.

Now, the use of -Wunused-but-set-variable in the autoconf
tests was introduced by commit b9c59ec8 to address a gcc
4.6 compatibility problem.  So we really only need to pass
this option for version of gcc which are known to support it.

Therefore, the tests have been updated to use the result of
the existing ZFS_AC_CONFIG_ALWAYS_NO_UNUSED_BUT_SET_VARIABLE
which determines if gcc supports this option.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1004

11 years ago'zfs send' man page sync'ed with Illumos
Steven Burgess [Fri, 28 Dec 2012 21:53:18 +0000 (16:53 -0500)]
'zfs send' man page sync'ed with Illumos

* Move -R option up one position in the list to match
  the Illumos documentation.

* Move -D option up one position and refreshed it to
  match the Illumos documentation.

* Move -p option up one position and refreshed it to
  match the Illumos documentation.

* Add the -n, -P  documentation found in zfs receive
  in to zfs send where to belongs.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1187

11 years ago'zfs receive' man page sync'ed with Illumos
Steven Burgess [Fri, 28 Dec 2012 21:36:10 +0000 (16:36 -0500)]
'zfs receive' man page sync'ed with Illumos

The only valid options are -vnFu, these other ones seem to be
misplaced zfs send options.

Remove: -D -r -p -n -P

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1186

11 years agoAdd /sbin/fsck.zfs helper
Brian Behlendorf [Wed, 9 Jan 2013 20:51:29 +0000 (12:51 -0800)]
Add /sbin/fsck.zfs helper

A fsck helper to accomidate distributions that expect to be able
to execute a fsck on all filesystem types.  Currently this script
does nothing but it could be extended to act as a compatibility
wrapper for 'zpool scrub'.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #964

11 years agoReport realpath() canonicalization error
Brian Behlendorf [Wed, 9 Jan 2013 19:56:37 +0000 (11:56 -0800)]
Report realpath() canonicalization error

Rather than just reporting the failure include the passed
mount point and error number.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1153

11 years agocall_usermodehelper() should wait for process
Ned Bass [Wed, 9 Jan 2013 23:46:31 +0000 (15:46 -0800)]
call_usermodehelper() should wait for process

As of Linux 3.4 the UMH_WAIT_* constants were renumbered.  In
particular, the meaning of "1" changed from UMH_WAIT_PROC (wait for
process to complete), to UMH_WAIT_EXEC (wait for the exec, but not the
process).  A number of call sites used the number 1 instead of the
constant name, so the behavior was not as expected on kernels with this
change.

One visible consequence of this change was that processes accessing
automounted snapshots received an ELOOP error because they failed to
wait for zfs.mount to complete.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #816

11 years agoRevert "Avoid ELOOP on auto-mounted snapshots"
Brian Behlendorf [Wed, 9 Jan 2013 19:09:06 +0000 (11:09 -0800)]
Revert "Avoid ELOOP on auto-mounted snapshots"

This reverts commit 7afcf5b1da83549bfba70a61fae7a00eaa63c2b0 which
accidentally introduced a regression with the .zfs snapshot directory.
While the updated code still does correctly mount the requested
snapshot.  It updates the vfsmount such that it references the
original dataset vfsmount.  The result is that the snapshot itself
isn't visible.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #816

11 years agoOnly reduce __zio_execute() stack usage in kernel space
Brian Behlendorf [Wed, 9 Jan 2013 00:16:46 +0000 (16:16 -0800)]
Only reduce __zio_execute() stack usage in kernel space

Related to 91579709fccd3e55a21970742b66c388fb1403db we need to
be very careful about not overrunning the stack in kernel space.
However, in user space we're already allowing slightly larger
stacks so this stack usage optimization is not required there.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
11 years agoMerge branch 'feature-flags'
Brian Behlendorf [Tue, 8 Jan 2013 18:59:05 +0000 (10:59 -0800)]
Merge branch 'feature-flags'

Feature flags support for ZFS ported from Illumos.  Only minimal
compatibility changes were made where required to accomidate Linux.
For a detailed description of feature flags see original proposal
on zfs-discuss.  They are conceptually very similar to Linux's
ext[234] style of feature flags.

http://lists.freebsd.org/pipermail/freebsd-fs/2011-May/011568.html

NOTE: This branch updates the default pool version for new pools
from 28 to 5000.  Version 28 pools may still be created for
compatibility with Solaris by using the '-o version=28' option.

$ zpool create -o version=28 ...

Existing pools must be manually upgraded using 'zpool upgrade'.

$ zpool upgrade ...

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #778

11 years agoIllumos #3145, #3212
George Wilson [Fri, 21 Dec 2012 22:57:09 +0000 (14:57 -0800)]
Illumos #3145, #3212

3145 single-copy arc
3212 ztest: race condition between vdev_online() and spa_vdev_remove()

Reviewed by: Matt Ahrens <matthew.ahrens@delphix.com>
Reviewed by: Adam Leventhal <ahl@delphix.com>
Reviewed by: Eric Schrock <eric.schrock@delphix.com>
Reviewed by: Justin T. Gibbs <gibbs@scsiguy.com>
Approved by: Eric Schrock <eric.schrock@delphix.com>

References:
  illumos-gate/commit/9253d63df408bb48584e0b1abfcc24ef2472382e
  illumos changeset: 13840:97fd5cdf328a
  https://www.illumos.org/issues/3145
  https://www.illumos.org/issues/3212

Ported-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #989
Closes #1137

11 years agoIllumos #3104: eliminate empty bpobjs
Matthew Ahrens [Sun, 23 Dec 2012 23:57:14 +0000 (15:57 -0800)]
Illumos #3104: eliminate empty bpobjs

3104 eliminate empty bpobjs
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Adam Leventhal <ahl@delphix.com>
Reviewed by: Christopher Siden <chris.siden@delphix.com>
Reviewed by: Garrett D'Amore <garrett@damore.org>
Approved by: Eric Schrock <eric.schrock@delphix.com>

References:
  illumos/illumos-gate@f17457368189aa911f774c38c1f21875a568bdca
  illumos changeset: 13782:8f78aae28a63
  https://www.illumos.org/issues/3104

Ported-by: Brian Behlendorf <behlendorf1@llnl.gov>
11 years agoFix __zio_execute() asynchronous dispatch
Brian Behlendorf [Tue, 18 Dec 2012 00:23:27 +0000 (16:23 -0800)]
Fix __zio_execute() asynchronous dispatch

To save valuable stack all zio's were made asynchronous when in the
tgx_sync_thread context or during pool initialization.  See commit
2fac4c2 for the original patch and motivation.

Unfortuantely, the changes to dsl_pool_sync_context() made by the
feature flags broke this logic causing in __zio_execute() to dispatch
itself infinitely when called during pool initialization.  This
commit refines the existing logic to specificly target only the two
cases we care about.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
11 years agoIllumos #3349: zpool upgrade -V bumps the on disk version number
George Wilson [Sat, 15 Dec 2012 00:28:49 +0000 (16:28 -0800)]
Illumos #3349: zpool upgrade -V bumps the on disk version number

3349 zpool upgrade -V bumps the on disk version number, but leaves
the in core version
Reviewed by: Adam Leventhal <ahl@delphix.com>
Reviewed by: Christopher Siden <chris.siden@delphix.com>
Reviewed by: Matt Ahrens <matthew.ahrens@delphix.com>
Reviewed by: Richard Lowe <richlowe@richlowe.net>
Approved by: Dan McDonald <danmcd@nexenta.com>

References:
  illumos/illumos-gate@25345e466695fbe736faa53b8f3413d8e8f81981
  https://www.illumos.org/issues/3349

Ported-by: Brian Behlendorf <behlendorf1@llnl.gov>
11 years agoIllumos #3086: unnecessarily setting DS_FLAG_INCONSISTENT on async
Matthew Ahrens [Sat, 15 Dec 2012 00:13:40 +0000 (16:13 -0800)]
Illumos #3086: unnecessarily setting DS_FLAG_INCONSISTENT on async

3086 unnecessarily setting DS_FLAG_INCONSISTENT on async
destroyed datasets
Reviewed by: Christopher Siden <chris.siden@delphix.com>
Approved by: Eric Schrock <Eric.Schrock@delphix.com>

References:
  illumos/illumos-gate@ce636f8b38e8c9ff484e880d9abb27251a882860
  illumos changeset: 13776:cd512c80fd75
  https://www.illumos.org/issues/3086

Ported-by: Brian Behlendorf <behlendorf1@llnl.gov>
11 years agoIllumos #2762: zpool command should have better support for feature flags
Christopher Siden [Fri, 14 Dec 2012 23:00:45 +0000 (15:00 -0800)]
Illumos #2762: zpool command should have better support for feature flags

2762 zpool command should have better support for feature flags
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: George Wilson <george.wilson@delphix.com>
Approved by: Eric Schrock <Eric.Schrock@delphix.com>

References:
  illumos/illumos-gate@57221772c3fc05faba04bf48ddff45abf2bbf2bd
  https://www.illumos.org/issues/2762

Ported-by: Brian Behlendorf <behlendorf1@llnl.gov>
11 years agoIllumos #3090 and #3102
George Wilson [Fri, 14 Dec 2012 20:38:04 +0000 (12:38 -0800)]
Illumos #3090 and #3102

3090 vdev_reopen() during reguid causes vdev to be treated as corrupt
3102 vdev_uberblock_load() and vdev_validate() may read the wrong label

Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Christopher Siden <chris.siden@delphix.com>
Reviewed by: Garrett D'Amore <garrett@damore.org>
Approved by: Eric Schrock <Eric.Schrock@delphix.com>

References:
  illumos/illumos-gate@dfbb943217bf8ab22a1a9d2e9dca01d4da95ee0b
  illumos changeset: 13777:b1e53580146d
  https://www.illumos.org/issues/3090
  https://www.illumos.org/issues/3102

Ported-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #939

11 years agoRevert "Temporarily disable the reguid test."
Brian Behlendorf [Fri, 14 Dec 2012 20:24:04 +0000 (12:24 -0800)]
Revert "Temporarily disable the reguid test."

This reverts commit d13524579162b35189804c357a63993be758b84c.
Since feature flags have now been merged we can apply the real
upstream fix from Illumos.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #997

11 years agoIllumos #2619 and #2747
Christopher Siden [Thu, 13 Dec 2012 23:24:15 +0000 (15:24 -0800)]
Illumos #2619 and #2747

2619 asynchronous destruction of ZFS file systems
2747 SPA versioning with zfs feature flags
Reviewed by: Matt Ahrens <mahrens@delphix.com>
Reviewed by: George Wilson <gwilson@delphix.com>
Reviewed by: Richard Lowe <richlowe@richlowe.net>
Reviewed by: Dan Kruchinin <dan.kruchinin@gmail.com>
Approved by: Eric Schrock <Eric.Schrock@delphix.com>

References:
  illumos/illumos-gate@53089ab7c84db6fb76c16ca50076c147cda11757
  illumos/illumos-gate@ad135b5d644628e791c3188a6ecbd9c257961ef8
  illumos changeset: 13700:2889e2596bd6
  https://www.illumos.org/issues/2619
  https://www.illumos.org/issues/2747

NOTE: The grub specific changes were not ported.  This change
must be made to the Linux grub packages.

Ported-by: Brian Behlendorf <behlendorf1@llnl.gov>
11 years agoFix duplicate words in zpool.8
Dominik Honnef [Fri, 4 Jan 2013 19:09:20 +0000 (20:09 +0100)]
Fix duplicate words in zpool.8

Remove the duplicate words 'cannot be' from the zpool.8 man page.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1177

11 years agoAllow fake mounts to succeed on non-legacy filesystems.
Will Rouesnel [Thu, 27 Dec 2012 14:44:16 +0000 (01:44 +1100)]
Allow fake mounts to succeed on non-legacy filesystems.

mountall in Debian depends on being able to pass the -f parameter to
mount, which specifies a fake mount and just updates the mtab. Currently
mount.zfs will fail such a request if it is not passed with -o zfsutil.

This patch allows a fake mount on a non-legacy filesystem to succeed in
the same manner as a -o remount does, thus enabling mountall to work
correctly.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1167

11 years agoFix gcc array subscript above bounds warning
Ned Bass [Wed, 26 Dec 2012 22:56:41 +0000 (14:56 -0800)]
Fix gcc array subscript above bounds warning

In a debug build, certain GCC versions flag an array bounds warning in
the below code from dnode_sync.c

    } else {
            int i;
            ASSERT(dn->dn_next_nblkptr[txgoff] < dnp->dn_nblkptr);
            /* the blkptrs we are losing better be unallocated */
            for (i = dn->dn_next_nblkptr[txgoff];
                i < dnp->dn_nblkptr; i++)
                    ASSERT(BP_IS_HOLE(&dnp->dn_blkptr[i]));

This usage is in fact safe, since the ASSERT ensures the index does
not exceed to maximum possible number of block pointers. However gcc
can't determine that the assignment 'i = dn->dn_next_nblkptr[txgoff];'
falls within the array bounds so it issues a warning.  To avoid this,
initialize i to zero to make gcc happy but skip the elements before
dn->dn_next_nblkptr[txgoff] in the loop body.  Since a dnode contains
at most 3 block pointers this overhead should be negligible.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #950

11 years agoMerge branch 'io_schedule'
Brian Behlendorf [Mon, 7 Jan 2013 18:54:56 +0000 (10:54 -0800)]
Merge branch 'io_schedule'

Currently ZFS doesn't show any I/O time in eg "top" wait% or in
/proc/$pid/stat's blkio_ticks.  Using io_schedule() instead of
schedule() in zio_wait()'s cv_wait() is the correct way to fix
this.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1158
Closes #1175

11 years agoUse cv_wait_io() which will will account for iowait
Matt Johnston [Fri, 21 Dec 2012 02:40:20 +0000 (10:40 +0800)]
Use cv_wait_io() which will will account for iowait

Update zio_wait() to use cv_wait_io() to ensure the iowait time
is properly accounted for.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
11 years agoRevert part of "Log I/Os longer than zio_delay_max (30s default)"
Matt Johnston [Fri, 21 Dec 2012 02:15:34 +0000 (10:15 +0800)]
Revert part of "Log I/Os longer than zio_delay_max (30s default)"

This reverts commit 9dcb97198338ba2d8764dd5604b278118612f74
which was originally introduced to debug occasional slow I/Os.
These I/Os would complete eventually but were observed to take
several 100 seconds.

The root cause of this issue was the CFQ scheduler which can,
under certain conditions, excessively delay an I/O from being
issued to the device.  This issue was mitigated somewhat by
commit 84daaddedbfc9cf4bd1490d8a6f4b2967051e308 which ensures
the I/O elevator gets changed even for DM style devices.

This change isn't in any way harmful but it does conflict with
a required change to properly account from I/O wait time.
Because Linux does not export the io_schedule_timeout() function
we must instead rely  on io_schedule() via cv_wait_io().

The additional debugging information which was added to the
delay event has been intentionally left in place.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
12 years agoZFS 0.6.0-rc13 zfs-0.6.0-rc13
Brian Behlendorf [Thu, 20 Dec 2012 19:02:24 +0000 (11:02 -0800)]
ZFS 0.6.0-rc13

12 years agoFix zpool on zvol lock inversion deadlock
Brian Behlendorf [Wed, 19 Dec 2012 21:51:44 +0000 (13:51 -0800)]
Fix zpool on zvol lock inversion deadlock

In all but one case the spa_namespace_lock is taken before the
bdev->bd_mutex lock.  But Linux __blkdev_get() function calls
fops->open() with the bdev->bd_mutex lock held and we must
somehow still safely acquire the spa_namespace_lock.

To avoid a potential lock inversion deadlock we preemptively
try to take the spa_namespace_lock().  Normally it will not
be contended and this is safe because spa_open_common() handles
the case where the caller already holds the spa_namespace_lock.

When it is contended we risk a lock inversion if we were to
block waiting for the lock.  Luckily, the __blkdev_get()
function allows us to return -ERESTARTSYS which will result in
bdev->bd_mutex being dropped, reacquired, and fops->open() being
called again.  This process can be repeated safely until both
locks are acquired.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Jorgen Lundman <lundman@lundman.net>
Closes #612

12 years agoRevert "Remove TSD zfs_fsyncer_key"
Brian Behlendorf [Thu, 20 Dec 2012 17:55:47 +0000 (09:55 -0800)]
Revert "Remove TSD zfs_fsyncer_key"

This reverts commit 31f2b5abdf95d8426d8bfd66ca7f62ec70215e3c back
to the original code until the fsync(2) performance regression
can be addressed.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
12 years agoRefresh AUTHORS
Brian Behlendorf [Wed, 19 Dec 2012 17:47:25 +0000 (09:47 -0800)]
Refresh AUTHORS

The AUTHORS file was getting stale.  Refresh its contents
using the authors listed in the git commit logs.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
12 years agoRemove the ChangeLog
Brian Behlendorf [Wed, 19 Dec 2012 17:22:07 +0000 (09:22 -0800)]
Remove the ChangeLog

The ChangeLog was retired long ago, the git commit logs are
authoritative.  To avoid any confusion remove the ChangeLog.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
12 years agoRemove TSD zfs_fsyncer_key
Brian Behlendorf [Thu, 13 Dec 2012 20:21:11 +0000 (12:21 -0800)]
Remove TSD zfs_fsyncer_key

It's my understanding that the zfs_fsyncer_key TSD was added as
a performance omtimization to reduce contention on the zl_lock
from zil_commit().  This issue manifested itself as very long
(100+ms) fsync() system call times for fsync() heavy workloads.

However, under Linux I'm not seeing the same contention that
was originally described.  Therefore, I'm removing this code
in order to ween ourselves off any dependence on TSD.  If the
original performance issue reappears on Linux we can revisit
fixing it without resorting to TSD.

This just leaves one small ZFS TSD consumer.  If it can be
cleanly removed from the code we'll be able to shed the SPL
TSD implementation entirely.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes zfsonlinux/spl#174

12 years agoSet elevator for DM devices despite vdev_wholedisk
Prakash Surya [Sat, 15 Dec 2012 00:16:35 +0000 (16:16 -0800)]
Set elevator for DM devices despite vdev_wholedisk

The current state of udev and devicer-mapper devices makes it difficult
to construct a mapping of DM partitions and their underlying DM device.
For example, with a /dev directory with the following contents:

    $ ls -d /dev/dm-*
    /dev/dm-0
    /dev/dm-1
    /dev/dm-2
    /dev/dm-3

it is not immediately apparent if these are completely separate devices,
or partitions and real devices intermixed. In contrast, SCSI devices
would appear as so:

    $ ls -d /dev/sd*
    /dev/sda
    /dev/sda1
    /dev/sdb
    /dev/sdb1

Here, one can immediately determine that there are two devices (sda and
sdb), each containing a single partition. The lack of a predictable and
consistent mapping from DM devices to DM device partitions makes it
difficult for user space to process these devices the same way it does
SCSI devices.

As a result, the ZFS utilities do not partition DM devices, and instead
set the "vdev_wholedisk" label to 0 and treat them as partitions. This
has the side effect that, even if ZFS has sole ownership of the device,
the IO scheduler will not be modified because it is treated as a
partition.

This change adds an exception for DM devices in vdev_elevator_switch,
allowing the elevator to be modified even though the "vdev_wholedisk"
property is not set.

Signed-off-by: Prakash Surya <surya1@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1149

12 years agoFix using zvol as slog device
Jorgen Lundman [Mon, 17 Dec 2012 01:33:57 +0000 (10:33 +0900)]
Fix using zvol as slog device

During the original ZoL port the vdev_uses_zvols() function was
disabled until it could be properly implemented.  This prevented
a zpool from use a zvol for its slog device.

This patch implements that missing functionality by adding a
zvol_is_zvol() function to zvol.c.  Given the full path to a
device it will lookup the device and verify its major number
against the registered zvol major number for the system.  If
they match we know the device is a zvol.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1131

12 years agoFix get/set users/groups in quota props via numeric id
Massimo Maggi [Sun, 16 Dec 2012 13:33:51 +0000 (14:33 +0100)]
Fix get/set users/groups in quota props via numeric id

Fix setting/getting users/groups in quota properties through
numeric identifier.  This support was accidentally disabled
in the original port by applying the HAVE_IDMAP wrapper macro
too broadly.

Fix obtained by moving #ifdef HAVE_IDMAP to exclude only
the part of code that really needs IDMAP.  Now zfs (get|set)
(user|group)quota@1000 works as expected.

Signed-off-by: Massimo Maggi <massimo@mmmm.it>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1147

12 years agoDo not use KERNEL_DIR env var in Makefile.am
Richard Yao [Sun, 16 Dec 2012 05:35:16 +0000 (00:35 -0500)]
Do not use KERNEL_DIR env var in Makefile.am

A Gentoo user reported an issue where the build system would
attempt to recurse into the kernel source tree if KERNEL_DIR
is set in the environment. KERNEL_DIR is an environment variable
that is used when the kernel sources are in a non-standard
location, so it is necessary to stop relying on it to prevent
this issue.

https://bugs.gentoo.org/show_bug.cgi?id=433946

Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
12 years agoUpdate SAs when an inode is dirtied
Brian Behlendorf [Wed, 12 Dec 2012 00:58:44 +0000 (16:58 -0800)]
Update SAs when an inode is dirtied

Revert the portion of commit d3aa3ea which always resulted in the
SAs being update when an mmap()'ed file was closed.  That change
accidentally resulted in unexpected ctime updates which upset tools
like git.  That was always a horrible hack and I'm happy it will
never make it in to a tagged release.

The right fix is something I initially resisted doing because I
was worried about the additional overhead.  However, in hindsight
the overhead isn't as bad as I feared.

This patch implemented the sops->dirty_inode() callback which is
unsurprisingly called when an inode is dirtied.  We leverage this
callback to keep the znode SAs strictly in sync with the inode.

However, for now we're going to go slowly to avoid introducing
any new unexpected issues by only updating the atime, mtime, and
ctime.  This will cover the callpath of most concern to us.

  ->filemap_page_mkwrite->file_update_time->update_time->
      mark_inode_dirty_sync->__mark_inode_dirty->dirty_inode

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #764
Closes #1140

12 years agoUpdate 69-vdev.rules .gitignore
Brian Behlendorf [Fri, 14 Dec 2012 19:45:41 +0000 (11:45 -0800)]
Update 69-vdev.rules .gitignore

Commit 2957f38 renamed 60-vdev.rules to 69-vdev.rules but failed
to update the .gitignore file to reflect this change.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
12 years agoAvoid ELOOP on auto-mounted snapshots
Ned Bass [Wed, 12 Dec 2012 23:55:51 +0000 (15:55 -0800)]
Avoid ELOOP on auto-mounted snapshots

Ensure that the path member pointers are associated with the
newly-mounted snapshot when zpl_snapdir_automount() returns.  Otherwise
the follow_automount() function may be called repeatedly, leading to an
incorrect ELOOP error return. This problem was observed as a 'Too many
levels of symbolic links' error from user-space commands accessing an
unmounted snapshot in the .zfs/snapshot directory.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #816

12 years agoLinux 3.7 compat, schedule_delayed_work()
Brian Behlendorf [Mon, 10 Dec 2012 18:15:12 +0000 (10:15 -0800)]
Linux 3.7 compat, schedule_delayed_work()

Linux kernel commit d8e794d accidentally broke the delayed work
APIs for non-GPL callers.   While the APIs to schedule a delayed
work item are still available to all callers, it is no longer
possible to initialize the delayed work item.

I'm cautiously optimistic we could get the delayed_work_timer_fn
exported for all callers in the upstream kernel.  But frankly
the compatibility code to use this kernel interface has always
been problematic.

Therefore, this patch abandons direct use the of the Linux
kernel interface in favor of the new delayed taskq interface.
It provides roughly the same functionality as delayed work queues
but it's a stable interface under our control.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1053

12 years agoSwitch KM_SLEEP to KM_PUSHPAGE
Richard Yao [Sat, 8 Dec 2012 13:38:13 +0000 (08:38 -0500)]
Switch KM_SLEEP to KM_PUSHPAGE

When writes to zvols invoke ZIL, zfs_range_new_proxy() is called,
which allocates memory using KM_SLEEP, triggering a warning.
Switch to KM_PUSHPAGE to silence that warning.  See commit
b8d06fca089fae4680c3a552fc55c512bfb02202 for additional details.

Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1138

12 years agoRevert "Fix unlink/xattr deadlock"
Brian Behlendorf [Wed, 5 Dec 2012 21:00:49 +0000 (13:00 -0800)]
Revert "Fix unlink/xattr deadlock"

This reverts commit b00131d43ca344d4b205a03ab3eb771a060e5087 which
is no longer needed due to e89260a1c8851ce05ea04b23606ba438b271d890.

This change forces all xattr znodes to hold a reference on their
parent which ensures prune_icache() will never attempt to evict
both the parent and child concurrently.  This effectively prevents
the deadlock condition from ever occuring.

Therefore we can safely revert back to the upstream synchronous
cleanup code.  This is nice because it keeps our code base closer
to upstream and resolves the performance issues introduced by the
original deadlock fix.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #457

12 years agoPreserve inode mtime/ctime in .writepage()
Brian Behlendorf [Tue, 4 Dec 2012 20:11:02 +0000 (12:11 -0800)]
Preserve inode mtime/ctime in .writepage()

When updating a file via mmap()'ed I/O preserve the mtime/ctime
which were updated when the page was made writable by the generic
callback filemap_page_mkwrite().

But more importantly than preserving the exact time add the missing
call to sa_bulk_update().  This ensures that the znode modifications
are written to disk as part of the transaction.  Without this the
inode may mistaken rollback to the previous on-disk znode state.

Additionally, for mmap()'ed znodes explicitly set the atime, mtime,
and ctime on close using the up to date values in the inode.  This
is critical because writepage() may occur after close and on close
we need to ensure the values are correct.

Original-patch-by: Richard Yao <ryao@cs.stonybrook.edu>
Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #764

12 years agoFix 'zpool create' segfault due to bad syntax
Jorgen Lundman [Thu, 29 Nov 2012 05:56:07 +0000 (14:56 +0900)]
Fix 'zpool create' segfault due to bad syntax

Incorrect syntax should never cause a segfault.  In this case
listing multiple comma delimited options after '-o' triggered
the problem.  For example:

  zpool create -o ashift=12,listsnaps=on

This patch resolves the issue by wrapping the calls which use
hdr with a NULL test.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1118

12 years agovdev_id support for device link aliases
Ned Bass [Thu, 29 Nov 2012 19:08:37 +0000 (11:08 -0800)]
vdev_id support for device link aliases

Add a vdev_id feature to map device names based on already defined
udev device links.  To increase the odds that vdev_id will run after
the rules it depends on, increase the vdev.rules rule number from 60
to 69.  With this change, vdev_id now provides functionality analogous
to zpool_id and zpool_layout, paving the way to retire those tools.

A defined alias takes precedence over a topology-derived name, but the
two naming methods can otherwise coexist. For example, one might name
drives in a JBOD with the sas_direct topology while naming an internal
L2ARC device with an alias.

For example, the following lines in vdev_id.conf will result in the
creation of links /dev/disk/by-vdev/{d1,d2}, each pointing to the same
target as the device link specified in the third field.

  #     by-vdev
  #     name     fully qualified or base name of device link
  alias d1       /dev/disk/by-id/wwn-0x5000c5002de3b9ca
  alias d2       wwn-0x5000c5002def789e

Also perform some minor vdev_id cleanup, such as removal of the unused
-s command line option.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #981

12 years agoDirectory xattr znodes hold a reference on their parent
Brian Behlendorf [Fri, 30 Nov 2012 00:10:03 +0000 (16:10 -0800)]
Directory xattr znodes hold a reference on their parent

Unlike normal file or directory znodes, an xattr znode is
guaranteed to only have a single parent.  Therefore, we can
take a refernce on that parent if it is provided at create
time and cache it.  Additionally, we take care to cache it
on any subsequent zfs_zaccess() where the parent is provided
as an optimization.

This allows us to avoid needing to do a zfs_zget() when
setting up the SELinux security xattr in the create path.
This is critical because a hash lookup on the directory
will deadlock since it is locked.

The zpl_xattr_security_init() call has also been moved up
to the zpl layer to ensure TXs to create the required
xattrs are performed after the create TX.  Otherwise we
run the risk of deadlocking on the open create TX.

Ideally the security xattr should be fully constructed
before the new inode is unlocked.  However, doing so would
require far more extensive changes to ZFS.

This change may also have the benefitial side effect of
ensuring xattr directory znodes are evicted from the cache
before normal file or directory znodes due to the extra
reference.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #671

12 years agoImplemented sharing datasets via SMB using libshare
Turbo Fredriksson [Sat, 4 Feb 2012 20:08:53 +0000 (21:08 +0100)]
Implemented sharing datasets via SMB using libshare

Add the initial support for the 'smbshare' option using the
existing libshare infrastructure.  Because this implementation
relies on usershares samba version 3.0.23 is required.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #493

12 years agoMake zpool attach -o ashift=... actually work
Cyril Plisko [Fri, 30 Nov 2012 21:13:28 +0000 (23:13 +0200)]
Make zpool attach -o ashift=... actually work

Commit df83110856950c8e7b16a7e94cdf42b8531b9cc8 missed update to
getopt() call, while delivering all the rest. This commit adds
"o" to getopt().

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #566

12 years agoAdd load_nvlist() error handling
Brian Behlendorf [Fri, 30 Nov 2012 19:23:38 +0000 (11:23 -0800)]
Add load_nvlist() error handling

Add the missing error handling to load_nvlist().  There's no good
reason this needs to be fatal.  All callers of load_nvlist() do
correctly handle an error condition and it is preferable that an
error be returned.  This will allow 'zpool import -FX' to safely
attempt to rollback through previous txgs looking for a good one.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1120

12 years agoAllow GPT+EFI vdevs for root pools
Brian Behlendorf [Tue, 6 Nov 2012 19:33:24 +0000 (11:33 -0800)]
Allow GPT+EFI vdevs for root pools

Commit 57a4edd allows the bootfs property to be set on any pool.
However, many of the zpool commands still prevent you from using
EFI labeled devices for the root pool.  For example:

    # zpool attach rpool /dev/sda /dev/sdb
    cannot label 'sdb': EFI labeled devices are not supported on
    root pools. on root devices.

For non-Solaris builds such as Linux disable this error.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1077

12 years agoDisable page allocation warnings for super block
Brian Behlendorf [Fri, 30 Nov 2012 18:31:54 +0000 (10:31 -0800)]
Disable page allocation warnings for super block

Due to the slightly increased size of the ZFS super block
caused by 30315d2 there are now allocation warnings.  The
allocation size is still small (just over 8k) and super
blocks are rarely allocated so we suppress the warning.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #1101

12 years agoVerify --with-linux source directory exists
Brian Behlendorf [Fri, 30 Nov 2012 04:19:25 +0000 (20:19 -0800)]
Verify --with-linux source directory exists

Previously this check was only performed when ./configure was
attempting to autodetect your kernel source directory.  But we
should also handle the case where --with-linux was provided
and is obviously wrong.  This way we catch the error before
invoking make and compiling the source with an incorrect
autoconf results.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes zfsonlinux/spl#162

12 years agovdev_id fails to handle complex device topologies
Cyril Plisko [Thu, 29 Nov 2012 13:40:26 +0000 (15:40 +0200)]
vdev_id fails to handle complex device topologies

While expanding positional parameters shell requires non-single
digits to be enclosed in braces. When the SAS topology is
non-trivial the number of positional parameters generated internally
by vdev_id script (using set -- ...) easily crosses single digit limit
and vdev_id fails to generate links.

Signed-off-by: Ned Bass <bass6@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1119

12 years agoMake vdev_id POSIX sh compatible
Ned Bass [Wed, 19 Sep 2012 18:44:12 +0000 (11:44 -0700)]
Make vdev_id POSIX sh compatible

Full bash may not be available in all environments where udev helpers
run, such as in an initial ramdisk.  To avoid breakage in this case,
remove use of bash-specific features such as variable arrays and the
`declare' keyword from the vdev_id script.

Signed-off-by: Ned Bass <bass6@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #870

12 years agoFix NULL deref when zvol_alloc() fails
Brian Behlendorf [Tue, 27 Nov 2012 22:02:49 +0000 (14:02 -0800)]
Fix NULL deref when zvol_alloc() fails

If zvol_alloc() fails zv will be set to NULL and dereferenced
in out_dmu_objset_disown.  To avoid this entirely the zv->objset
line is moved up in to the success block.

Original-patch-by: Jorgen Lundman <lundman@lundman.net>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1109

12 years agoIncrease ZFS_OBJ_MTX_SZ to 256
Brian Behlendorf [Tue, 27 Nov 2012 21:32:57 +0000 (13:32 -0800)]
Increase ZFS_OBJ_MTX_SZ to 256

Increasing this limit costs us 6144 bytes of memory per mounted
filesystem, but this is small price to pay for accomplishing
the following:

* Allows for up to 256-way concurreny when performing lookups
  which helps performance when there are a large number of
  processes.

* Minimizes the likelyhood of encountering the deadlock
  described in issue #1101.  Because vmalloc() won't strictly
  honor __GFP_FS there is still a very remote chance of a
  deadlock.  See the zfsonlinux/spl@043f9b57 commit.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1101

12 years agoRecreate minors when renaming zvols
Brian Behlendorf [Mon, 19 Nov 2012 21:48:06 +0000 (13:48 -0800)]
Recreate minors when renaming zvols

When a zvol with snapshots is renamed the device files under
/dev/zvol/ are not renamed.  This patch resolves the problem
by destroying and recreating the minors with the new name so
the links can be recreated bu udev.

Original-patch-by: Suman Chakravartula <schakrava@gmail.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #408

12 years agomount.zfs: canonicalize mount point for mtab
nordaux [Mon, 13 Feb 2012 03:44:20 +0000 (05:44 +0200)]
mount.zfs: canonicalize mount point for mtab

Canonicalize the mount point passed to the mount.zfs helper.
This way a clean path is always added to mtab which ensures
the umount can properly locate and remove the entry.

Test case:
$ mkdir /mnt/foo
$ mount -t zfs zpool/foo /mnt/../mnt/foo////
$ umount /mnt/foo
$ cat /etc/mtab | grep zpool/foo
zpool/foo /mnt/../mnt/foo//// zfs rw 0 0

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #573

12 years agoMerge branch 'ashift'
Brian Behlendorf [Thu, 15 Nov 2012 19:43:54 +0000 (11:43 -0800)]
Merge branch 'ashift'

This branch adds some overdue ashift improvements.

  * Add '-o ashift' to 'zpool add' and 'zpool attach'
  * Improve AF hard disk detection
  * Allow 'zpool import' to handle increases in ashift

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
12 years agoAdd "-o ashift" to zpool add and zpool attach
Cyril Plisko [Tue, 6 Nov 2012 12:39:00 +0000 (14:39 +0200)]
Add "-o ashift" to zpool add and zpool attach

When adding devices to an existing pool "ashift" property is
auto-detected.  However, if this property was overridden at
the pool creation time (i.e. zpool create -o ashift=12 tank ...)
this may not be what the user wants.  This commit lets the user
specify the value of "ashift" property to be used with newly
added drives. For example,

    zpool add -o ashift=12 tank disk1
    zpool attach -o ashift=12 tank disk1 disk2

Signed-off-by: Cyril Plisko <cyril.plisko@mountall.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #566

12 years agoImprove AF hard disk detection
Brian Behlendorf [Sun, 2 Sep 2012 23:34:12 +0000 (16:34 -0700)]
Improve AF hard disk detection

Use the bdev_physical_block_size() interface to determine the
minimize write size which can be issued without incurring a
read-modify-write operation.  This is used to set the ashift
correctly to prevent a performance penalty when using AF hard
disks.

Unfortunately, this interface isn't entirely reliable because
it's not uncommon for disks to misreport this value.  For this
reason you may still need to manually set your ashift with:

  zpool create -o ashift=12 ...

The solution to this in the upstream Illumos source was to add
a white list of known offending drives.  Maintaining such a list
will be a burden, but it still may be worth doing if we can
detect a large number of these drives.  This should be considered
as future work.

Reported-by: Richard Yao <ryao@cs.stonybrook.edu>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #916

12 years agoIllumos #2671: zpool import should not fail if vdev ashift has increased
George Wilson [Thu, 3 May 2012 12:49:19 +0000 (05:49 -0700)]
Illumos #2671: zpool import should not fail if vdev ashift has increased

Reviewed by: Adam Leventhal <ahl@delphix.com>
Reviewed by: Eric Schrock <eric.schrock@delphix.com>
Reviewed by: Richard Elling <richard.elling@richardelling.com>
Reviewed by: Gordon Ross <gwr@nexenta.com>
Reviewed by: Garrett D'Amore <garrett@damore.org>
Approved by: Richard Lowe <richlowe@richlowe.net>

Refererces to Illumos issue:
      https://www.illumos.org/issues/2671

This patch has been slightly modified from the upstream Illumos
version.  In the upstream implementation a warning message is
logged to the console.  To prevent pointless console noise this
notification is now posted as a "ereport.fs.zfs.vdev.bad_ashift"
event.

The event indicates a non-optimial (but entirely safe) ashift
value was used to create the pool.  Depending on your workload
this may impact pool performance.  Unfortunately, the only way
to correct the issue is to recreate the pool with a new ashift.

NOTE: The unrelated fix to the comment in zpool_main.c appears
in the upstream commit and was preserved for consistnecy.

Ported-by: Cyril Plisko <cyril.plisko@mountall.com>
Reworked-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #955

12 years agozfs-0.6.0-rc12 zfs-0.6.0-rc12
Brian Behlendorf [Tue, 13 Nov 2012 22:35:44 +0000 (14:35 -0800)]
zfs-0.6.0-rc12

12 years agoFix hard coded path in 60-vdev.rules.in
Richard Yao [Mon, 12 Nov 2012 17:34:45 +0000 (12:34 -0500)]
Fix hard coded path in 60-vdev.rules.in

The udev data directory was hard coded in 60-vdev.rules.in. That causes
a problem when a distribution changes the location of the directory.
This was not an issue in the past because virtually all distributions
used the same path, but that is beginning to change following a decision
by the systemd developers to change the directory location to reflect
their take-over of udev maintainership. The testing branch of Gentoo
Linux adopted this change, which enabled the hardcoded directory
location to trigger a regression.

Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1085

12 years agoFix "allocating allocated segment" panic
Brian Behlendorf [Wed, 31 Oct 2012 17:06:34 +0000 (10:06 -0700)]
Fix "allocating allocated segment" panic

Gunnar Beutner did all the hard work on this one by correctly
identifying that this issue is a race between dmu_sync() and
dbuf_dirty().

Now in all cases the caller is responsible for preventing this
race by making sure the zfs_range_lock() is held when dirtying
a buffer which may be referenced in a log record.  The mmap
case which relies on zfs_putpage() was not taking the range
lock.  This code was accidentally dropped when the function
was rewritten for the Linux VFS.

This patch adds the required range locking to zfs_putpage().

It also adds the missing ZFS_ENTER()/ZFS_EXIT() macros which
aren't strictly required due to the VFS holding a reference.
However, this makes the code more consistent with the upsteam
code and there's no harm in being extra careful here.

Original-patch-by: Gunnar Beutner <gunnar@beutner.name>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #541

12 years agoFix zvol+btrfs hang
Brian Behlendorf [Thu, 8 Nov 2012 22:18:22 +0000 (14:18 -0800)]
Fix zvol+btrfs hang

When using a zvol to back a btrfs filesystem the btrfs mount
would hang.  This was due to the bio completion callback used
in btrfs assuming that lower level drivers would never modify
the bio->bi_io_vecs after they were submitted via bio_submit().
If they are modified btrfs will miscalculate which pages need
to be unlocked resulting in a hang.

It's worth mentioning that other file systems such as ext[234]
and xfs work fine because they do not make the same assumption
in the bio completion callback.

The most straight forward way to fix the issue is to present
the semantics expected by btrfs.  This is done by cloning the
bios attached to each request and then using the clones bvecs
to perform the required accounting.  The clones are freed after
each read/write and the original unmodified bios are linked back
in to the request.

Signed-off-by: Chris Wedgwood <cw@f00f.org>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #469

12 years agoMerge remote branch 'eris/stats'
Brian Behlendorf [Tue, 6 Nov 2012 22:44:07 +0000 (14:44 -0800)]
Merge remote branch 'eris/stats'

Bring in support for the new KSTAT_TYPE_TXG type.  This allows for
additional visibility in to the txg handling.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
12 years agoLog I/Os longer than zio_delay_max (30s default)
Brian Behlendorf [Thu, 25 Oct 2012 20:02:31 +0000 (13:02 -0700)]
Log I/Os longer than zio_delay_max (30s default)

There have been reports of ZFS deadlocking due to what appears to
be a lost IO.  This patch addes some debugging to determine the
exact state of the IO which neither 1) completed, 2) failed, or
3) timed out after zio_delay_max (30) seconds.

This information will be logged using the ZFS FMA infrastructure
as a 'delay' event and posted to the internal zevent log.  By
default the last 64 events will be kept in the log but the limit
is configurable via the zfs_zevent_len_max module option.

To dump the contents of the log use the 'zpool events -v' command
and look for the resource.fs.zfs.delay event.  It will include
various information about the pool, vdev, and zio which may shed
some light on the issue.

In the context of this change the 120 second kernel blocked thread
watchdog has been disabled for synchronous IOs.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #930

12 years agoAdd txgs-<pool> kstat file
Brian Behlendorf [Tue, 23 Oct 2012 20:48:22 +0000 (13:48 -0700)]
Add txgs-<pool> kstat file

Create a kstat file which contains useful statistics about the
last N txgs processed.  This can be helpful when analyzing pool
performance.  The new KSTAT_TYPE_TXG type was added for this
purpose and it tracks the following statistics per-txg.

  txg          - Unique txg number
  state        - State (O)pen/(Q)uiescing/(S)yncing/(C)ommitted
  birth;       - Creation time
  nread        - Bytes read
  nwritten;    - Bytes written
  reads        - IOPs read
  writes       - IOPs write
  open_time;   - Length in nanoseconds the txg was open
  quiesce_time - Length in nanoseconds the txg was quiescing
  sync_time;   - Length in nanoseconds the txg was syncing

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
12 years agoAdd ddt_object_count() error handling
Brian Behlendorf [Fri, 26 Oct 2012 17:01:49 +0000 (10:01 -0700)]
Add ddt_object_count() error handling

The interface for the ddt_zap_count() function assumes it can
never fail.  However, internally ddt_zap_count() is implemented
with zap_count() which can potentially fail.  Now because there
was no way to return the error to the caller a VERIFY was used
to ensure this case never happens.

Unfortunately, it has been observed that pools can be damaged in
such a way that zap_count() fails.  The result is that the pool can
not be imported without hitting the VERIFY and crashing the system.

This patch reworks ddt_object_count() so the error can be safely
caught and returned to the caller.  This allows a pool which has
be damaged in this way to be safely rewound for import.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #910

12 years agoRevert "Don't ashift-align vdev read requests."
Brian Behlendorf [Wed, 24 Oct 2012 22:22:31 +0000 (15:22 -0700)]
Revert "Don't ashift-align vdev read requests."

This reverts commit a5c20e2a0a9046c06d86615fbf51dc04f12bba14 which
accidentally introduced a regression for real 4k sector devices.
See issue #1065 for details.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #1065

12 years agoRemove 'Resized bio's/dio' warning
Brian Behlendorf [Mon, 22 Oct 2012 17:07:24 +0000 (10:07 -0700)]
Remove 'Resized bio's/dio' warning

The following warning was originally added to provide visibility
in to how often a dio gets heavily fragmented in to over 16 bios.
This can happen due to constraints imposed by the block device
and may have a negitive impact on performance but is otherwise
harmless.  To prevent needless confusion and worry the message
has been removed.

  kernel: WARNING: Resized bio's/dio to 32

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
12 years agoUpdate spare and cache device names on import
Brian Behlendorf [Fri, 19 Oct 2012 04:36:07 +0000 (21:36 -0700)]
Update spare and cache device names on import

During 'zpool import' all ZPOOL_CONFIG_PATH names are supposed
to be updated by fix_paths().  This was not happening for spare
and cache devices because the proper names were getting filtered
out of the pool_list_t->names.  Interestingly, the names were
being filtered because the spare and cache devices do not
contain the pool name in their vdev label.

The fix is to exclude the device path from the list only if:

  1) has a valid ZPOOL_CONFIG_POOL_NAME key in the label, and
  2) that pool name does not match the specified pool name.

Since the label is valid and because it does properly store the
vdev guid it will be correctly assembled without the pool name.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #725

12 years agoAllow 'zpool replace' to use short device names
Brian Behlendorf [Wed, 17 Oct 2012 23:58:54 +0000 (16:58 -0700)]
Allow 'zpool replace' to use short device names

The 'zpool replace' command would fail when given a short name
because unlike on other platforms the short name cannot be
deterministically expanded to a single path.  Multiple path
prefixes must be checked and in addition the partition suffix
for whole disks is determined by the prefix.

To handle this complexity a zfs_strcmp_pathname() function was
added which takes either a short or fully qualified device name.
Short names will be expanded using the prefixes in the default
import search path, or the ZPOOL_IMPORT_PATH environment variable
if it's defined.  All posible expansions are then compared against
the comparison path.  Care is taken to strip redundant slashes to
ensure legitimate matches are not missed.

In the context of this work the existing zfs_resolve_shortname()
function was extended to consider the ZPOOL_IMPORT_PATH when set.
The zfs_append_partition() interface was also simplified to take
only a single buffer.

The vast majority of these changes rework existing Linux specific
code which was originally written to accomidate udev.  However,
there is some minimal cleanup which removes Illumos specific code.
This was done to improve readability but the basic flow and intent
of the upstream code was maintained.

These changes are the logical conclusion of the previos work to
adjust the 'zpool import' search behavior, see commit 44867b6a.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #544
Closes #976

12 years agoQuote snapshot and mountpoint for .zfs automount
Brian Behlendorf [Wed, 17 Oct 2012 20:23:09 +0000 (13:23 -0700)]
Quote snapshot and mountpoint for .zfs automount

When automounting a snapshot in the .zfs/snapshot directory
make sure to quote both the dataset name and the mount point.
This ensures that if either component contains spaces, which
are allowed, they get handled correctly.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1027

12 years agoMerge branch 'zil-performance'
Brian Behlendorf [Wed, 17 Oct 2012 15:57:14 +0000 (08:57 -0700)]
Merge branch 'zil-performance'

This brnach brings some ZIL performance optimizations, with
significant increases in synchronous write performance for
some workloads and pool configurations.

See the individual commit messages for details.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1013

12 years agoUse the slog even with logbias=throughput.
Etienne Dechamps [Thu, 28 Jun 2012 10:30:07 +0000 (12:30 +0200)]
Use the slog even with logbias=throughput.

In the current code, logbias=throughput implies the following:
 1) All synchronous writes are logged in indirect mode.
 2) The slog is not used.

(1) makes sense because it avoids writing the data twice, which is
obviously a good thing when the user wants maximum pool throughput.

(2), however, is a surprising decision. Considering all writes are
indirect, the log record doesn't contain the actual data, only pointers
to DMU blocks. As a result, log records written in logbias=throughput
mode are quite small, and as such, it doesn't make any sense to write
them to the main pool since slogs are usually optimized for small
synchronous writes.

In fact, the current behavior is actually harmful for performance,
because log blocks and data blocks from dmu_sync() seldom have the same
allocation size and as a result are usually allocated from different
metaslabs. This means that if a spindle has to write both log blocks and
DMU blocks (which is likely to happen under heavy load), it will have to
seek between the two. Allocating the log blocks from the slog pool
instead of the main pool avoids these unnecessary seeks.

This commit makes ZFS use the slog on datasets with logbias=throughput.
Real-life performance testing shows a 50% synchronous write performance
increase with some large commit sizes, and no negative effect in other
cases.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #1013

12 years agoAdd FASTWRITE algorithm for synchronous writes.
Etienne Dechamps [Wed, 27 Jun 2012 13:20:20 +0000 (15:20 +0200)]
Add FASTWRITE algorithm for synchronous writes.

Currently, ZIL blocks are spread over vdevs using hint block pointers
managed by the ZIL commit code and passed to metaslab_alloc(). Spreading
log blocks accross vdevs is important for performance: indeed, using
mutliple disks in parallel decreases the ZIL commit latency, which is
the main performance metric for synchronous writes. However, the current
implementation suffers from the following issues:

1) It would be best if the ZIL module was not aware of such low-level
details. They should be handled by the ZIO and metaslab modules;

2) Because the hint block pointer is managed per log, simultaneous
commits from multiple logs might use the same vdevs at the same time,
which is inefficient;

3) Because dmu_write() does not honor the block pointer hint, indirect
writes are not spread.

The naive solution of rotating the metaslab rotor each time a block is
allocated for the ZIL or dmu_sync() doesn't work in practice because the
first ZIL block to be written is actually allocated during the previous
commit. Consequently, when metaslab_alloc() decides the vdev for this
block, it will do so while a bunch of other allocations are happening at
the same time (from dmu_sync() and other ZILs). This means the vdev for
this block is chosen more or less at random. When the next commit
happens, there is a high chance (especially when the number of blocks
per commit is slightly less than the number of the disks) that one disk
will have to write two blocks (with a potential seek) while other disks
are sitting idle, which defeats spreading and increases the commit
latency.

This commit introduces a new concept in the metaslab allocator:
fastwrites. Basically, each top-level vdev maintains a counter
indicating the number of synchronous writes (from dmu_sync() and the
ZIL) which have been allocated but not yet completed. When the metaslab
is called with the FASTWRITE flag, it will choose the vdev with the
least amount of pending synchronous writes. If there are multiple vdevs
with the same value, the first matching vdev (starting from the rotor)
is used. Once metaslab_alloc() has decided which vdev the block is
allocated to, it updates the fastwrite counter for this vdev.

The rationale goes like this: when an allocation is done with
FASTWRITE, it "reserves" the vdev until the data is written. Until then,
all future allocations will naturally avoid this vdev, even after a full
rotation of the rotor. As a result, pending synchronous writes at a
given point in time will be nicely spread over all vdevs. This contrasts
with the previous algorithm, which is based on the implicit assumption
that blocks are written instantaneously after they're allocated.

metaslab_fastwrite_mark() and metaslab_fastwrite_unmark() are used to
manually increase or decrease fastwrite counters, respectively. They
should be used with caution, as there is no per-BP tracking of fastwrite
information, so leaks and "double-unmarks" are possible. There is,
however, an assert in the vdev teardown code which will fire if the
fastwrite counters are not zero when the pool is exported or the vdev
removed. Note that as stated above, marking is also done implictly by
metaslab_alloc().

ZIO also got a new FASTWRITE flag; when it is used, ZIO will pass it to
the metaslab when allocating (assuming ZIO does the allocation, which is
only true in the case of dmu_sync). This flag will also trigger an
unmark when zio_done() fires.

A side-effect of the new algorithm is that when a ZIL stops being used,
its last block can stay in the pending state (allocated but not yet
written) for a long time, polluting the fastwrite counters. To avoid
that, I've implemented a somewhat crude but working solution which
unmarks these pending blocks in zil_sync(), thus guaranteeing that
linguering fastwrites will get pruned at each sync event.

The best performance improvements are observed with pools using a large
number of top-level vdevs and heavy synchronous write workflows
(especially indirect writes and concurrent writes from multiple ZILs).
Real-life testing shows a 200% to 300% performance increase with
indirect writes and various commit sizes.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #1013

12 years agoAdd atomic_sub_* functions to libspl.
Etienne Dechamps [Wed, 27 Jun 2012 08:26:49 +0000 (10:26 +0200)]
Add atomic_sub_* functions to libspl.

Both the SPL and the ZFS libspl export most of the atomic_* functions,
except atomic_sub_* functions which are only exported by the SPL, not by
libspl. This patch remedies that by implementing atomic_sub_* functions
in libspl.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #1013

12 years agoMerge branch 'condvar'
Brian Behlendorf [Wed, 17 Oct 2012 15:47:07 +0000 (08:47 -0700)]
Merge branch 'condvar'

Auditing the code to verify that all instances of cv_signal() and
cv_broadcast() are called under the proper associated mutex turned
up several races. None of these have been conclusively seen in the
wild but the following patch set resolves them.

For reference, from the cv_signal(9F) man page:

  cv_signal() signals the condition and wakes one blocked thread.
  All blocked threads can be unblocked by calling cv_broadcast().
  You must acquire the mutex passed into cv_wait() before calling
  cv_signal() or cv_broadcast()

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1048

12 years agoCondition variable usage, zp->r_{rd,wr}_cv
Brian Behlendorf [Mon, 15 Oct 2012 20:41:44 +0000 (13:41 -0700)]
Condition variable usage, zp->r_{rd,wr}_cv

The following incorrect usage of cv_broadcast() was caught by
code inspection.  The cv_broadcast() function must be called
under the associated mutex to preventing racing with cv_wait().

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
12 years agoCondition variable usage, zilog->zl_cv_batch
Brian Behlendorf [Mon, 15 Oct 2012 20:40:07 +0000 (13:40 -0700)]
Condition variable usage, zilog->zl_cv_batch

The following incorrect usage of cv_signal and cv_broadcast()
was caught by code inspection.  The cv_signal and cv_broadcast()
functions must be called under the associated mutex to preventing
racing with cv_wait().

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
12 years agoCondition variable usage, zevent_cv
Brian Behlendorf [Mon, 15 Oct 2012 20:36:26 +0000 (13:36 -0700)]
Condition variable usage, zevent_cv

The following incorrect usage of cv_broadcast() was caught by
code inspection.  The cv_broadcast() function must be called
under the associated mutex to preventing racing with cv_wait().

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
12 years agoDo not return /dev/loop-control in unused_loop_device
Andrew Reid [Sat, 13 Oct 2012 15:03:59 +0000 (12:03 -0300)]
Do not return /dev/loop-control in unused_loop_device

The function unused_loop_device in /usr/libexec/zfs/common.sh
returns /dev/loop-control on the first call. This device is NOT
a loop device (https://github.com/torvalds/linux/commit/770fe30)
it is a control device. This in turn causes the script zconfig.sh
to fail with:

  zpool-create.sh: Error 1 creating /tmp/zpool-vdev0 ->
  /dev/loop-control loopback

The patch makes the function return /dev/loop[0-9]* which are
loop devices.

Signed-off-by: Andrew Reid <ColdCanuck@nailedtotheperch.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #797

12 years agoSwitch KM_SLEEP to KM_PUSHPAGE
Massimo Maggi [Thu, 11 Oct 2012 22:55:42 +0000 (00:55 +0200)]
Switch KM_SLEEP to KM_PUSHPAGE

In this particular instance the allocation occurred in the context
of sys_msync()->...->zpl_putpage() where we must be careful not to
initiate additional I/O.

Signed-off-by: Massimo Maggi <massimo@mmmm.it>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1038

12 years agoLimit zfs_vdev_aggregation_limit to SPA_MAXBLOCKSIZE
Brian Behlendorf [Mon, 15 Oct 2012 16:27:48 +0000 (09:27 -0700)]
Limit zfs_vdev_aggregation_limit to SPA_MAXBLOCKSIZE

Prevent users from setting the zfs_vdev_aggregation_limit tuning
larger than SPA_MAXBLOCKSIZE.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #520

12 years agoReturn positive error number in zfsctl_shares_lookup.
Yuxuan Shui [Sun, 14 Oct 2012 09:01:26 +0000 (17:01 +0800)]
Return positive error number in zfsctl_shares_lookup.

Otherwise it will cause zpl_shares_lookup() to return a invalid
pointer when an error occurs.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Closes #626 #885 #947 #977

12 years agoDisable ztest deadman timer
Brian Behlendorf [Mon, 15 Oct 2012 02:21:49 +0000 (19:21 -0700)]
Disable ztest deadman timer

The ztest deadman timer has been causing false positives in the
testing VMs.  To make it easier to spot possible regressions
I'm disabling this timer.  The buildbot test infrastructure
will still mark ztest instances which take to long to complete
as failures.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #1018

12 years agoMerge branch 'linux-3.6'
Brian Behlendorf [Sun, 14 Oct 2012 23:27:22 +0000 (16:27 -0700)]
Merge branch 'linux-3.6'

This branch adds the required compatibility code to support the
Linux 3.6 kernel.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #873

12 years agoLinux 3.6 compat, iops->mkdir()
Richard Yao [Thu, 16 Aug 2012 23:31:54 +0000 (19:31 -0400)]
Linux 3.6 compat, iops->mkdir()

Use .mkdir instead of .create in 3.3 compatibility check.  Linux 3.6
modifies inode_operations->create's function prototype. This causes
an autotools Linux 3.3. compatibility check for a function prototype
change in create, mkdir and mknode to fail. Since mkdir and mknode
are unchanged, we modify the check to examine it instead.

Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #873

12 years agoLinux 3.6 compat, iops->create()
Yuxuan Shui [Fri, 12 Oct 2012 15:20:58 +0000 (23:20 +0800)]
Linux 3.6 compat, iops->create()

As of Linux commit ebfc3b49a7ac25920cb5be5445f602e51d2ea559 the
struct nameidata is no longer passed to iops->create.  Instead
only the result of (inamedata->flags & LOOKUP_EXCL) is passed.

ZFS like almost all Linux fileystems never made use of this so
only the prototype needs to be wrapped for compatibility.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #873

12 years agoLinux 3.6 compat, iops->lookup()
Yuxuan Shui [Fri, 12 Oct 2012 14:41:06 +0000 (22:41 +0800)]
Linux 3.6 compat, iops->lookup()

As of Linux commit 00cd8dd3bf95f2cc8435b4cac01d9995635c6d0b the
struct nameidata is no longer passed to iops->lookup.  Instead
only the inamedata->flags are passed.

ZFS like almost all Linux fileystems never made use of this so
only the prototype needs to be wrapped for compatibility.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #873

12 years agoLinux 3.6 compat, sget()
Yuxuan Shui [Fri, 12 Oct 2012 13:40:53 +0000 (21:40 +0800)]
Linux 3.6 compat, sget()

As of Linux commit 9249e17fe094d853d1ef7475dd559a2cc7e23d42 the
mount flags are now passed to sget() so they can be used when
initializing a new superblock.

ZFS never uses sget() in this fashion so we can simply pass a
zero and add a zpl_sget() compatibility wrapper.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #873

12 years agoLinux 3.6 compat, sops->write_super() removed
Yuxuan Shui [Sun, 14 Oct 2012 01:44:15 +0000 (18:44 -0700)]
Linux 3.6 compat, sops->write_super() removed

The .write_super callback was removed the the super_operations
structure by Linux commit f0cd2dbb6cf387c11f87265462e370bb5469299e.
All file systems are now expected to self manage writing any dirty
state assoicated with their super block.

ZFS never made use of this callback so it can simply be removed
from the super_operations structure.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #873

12 years agoDon't ashift-align vdev read requests.
Etienne Dechamps [Sun, 7 Oct 2012 19:30:23 +0000 (21:30 +0200)]
Don't ashift-align vdev read requests.

Currently, the size of read and write requests on vdevs is aligned
according to the vdev's ashift, allocating a new ZIO buffer and padding
if need be.

This makes sense for write requests to prevent read/modify/write if the
write happens to be smaller than the device's internal block size.

For reads however, the rationale is less clear. It seems that the
original code aligns reads because, on Solaris, device drivers will
outright refuse unaligned requests.

We don't have that issue on Linux. Indeed, Linux block devices are able
to accept requests of any size, and take care of alignment issues
themselves.

As a result, there's no point in enforcing alignment for read requests
on Linux. This is a nice optimization opportunity for two reasons:
- We remove a memory allocation in a heavily-used code path;
- The request gets aligned in the lowest layer possible, which shrinks
  the path that the additional, useless padding data has to travel.
  For example, when using 4k-sector drives that lie about their sector
  size, using 512b read requests instead of 4k means that there will
  be less data traveling down the ATA/SCSI interface, even though the
  drive actually reads 4k from the platter.

The only exception is raidz, because raidz needs to read the whole
allocated block for parity.

This patch removes alignment enforcement for read requests, except on
raidz. Note that we also remove an assertion that checks that we're
aligning a top-level vdev I/O, because that's not the case anymore for
repair writes that results from failed reads.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1022

12 years agoRemove vmem_size() consumers
Richard Yao [Thu, 11 Oct 2012 22:51:25 +0000 (15:51 -0700)]
Remove vmem_size() consumers

There are currently three vmem_size() consumers all of which are
part of the ARC implemention.  However, since the expected behavior
of the Linux and Solaris virtual memory subsystems are so different
the behavior in each of these instances needs to be reevaluated.

* arc_evict_needed() - This is actually dead code.  Arena support
was never added to the SPL and zio_arena is always NULL.  This
support isn't needed so we simply remove this dead code.

* arc_memory_throttle() - On Solaris where virtual memory constitutes
almost all of the address space we can reasonably expect there to be
a fairly large amount free.  However, on Linux by default we only
have about 100MB total and that's heavily used by the ARC.  So the
expectation on Linux is that this will usually be a small value.
Therefore we remove the vmem_size() check for i386 systems because
the expectation is that it will be less than the zfs_write_limit_max.

* arc_init() - Here vmem_size() is used to initially size the ARC.
Since the ARC is currently backed by the virtual address space it
makes sense to use this as a limit on the ARC for 32-bit systems.
This code can be removed when the ARC is backed by the page cache.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #831

12 years agoFix zfs_txg_timeout module parameter
Brian Behlendorf [Thu, 11 Oct 2012 20:56:32 +0000 (13:56 -0700)]
Fix zfs_txg_timeout module parameter

Allow the zfs_txg_timeout variable to be dynamically tuned at run
time.  By pulling it down out of the variable declaration it will
be evaluted each time through the loop.

The zfs_txg_timeout variable is now declared extern in a the common
sys/txg.h header rather than locally in dsl_scan.c.  This prevents
potential type mismatches if the global variable needs to be used
elsewhere.

Move the module_param() code in to the same source file where
zfs_txg_timeout is declared.  This is the most logical location.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
12 years agoFix zfs_write_limit_max integer size mismatch on 32-bit systems
Richard Yao [Thu, 11 Oct 2012 03:57:45 +0000 (23:57 -0400)]
Fix zfs_write_limit_max integer size mismatch on 32-bit systems

Commit c409e4647f221ab724a0bd10c480ac95447203c3 introduced a
number of module parameters.  This required several types to be
changed to accomidate the required module parameters Linux macros.

Unfortunately, arc.c contained its own extern definition of the
zfs_write_limit_max variable and its type was not updated to be
consistent with its dsl_pool.c counterpart.  If the variable had
been properly marked extern in a common header, then gcc would
have generated a warning and this would not have slipped through.

The result of this was that the ARC unconditionally expected
zfs_write_limit_max to be 64-bit. Unfortunately, the largest size
integer module parameter that Linux supports is unsigned long, which
varies in size depending on the host system's native word size. The
effect was that on 32-bit systems, ARC incorrectly performed 64-bit
operations on a 32-bit value by reading the neighboring 32 bits as
the upper 32 bits of the 64-bit value.

We correct that by changing the extern declaration to use the unsigned
long type and move these extern definitions in to the common arc.h
header. This should make ARC correctly treat zfs_write_limit_max as a
32-bit value on 32-bit systems.

Reported-by: Jorgen Lundman <lundman@lundman.net>
Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #749