7386 zfs get does not work properly with bookmarks
Reviewed by: Simon Klinkert <simon.klinkert@gmail.com>

refs #3150

7307 Fixing 5780 introduced a regression

6785 nfs4_attr_cache deadlock

Avoid a deadlock with the r_serial thread waiting for
os_sync_lock in nfs4_get_otw_cred_by_osp() which might be
held by the nfs4close_otw thread. This thread would
wait

6785 nfs4_attr_cache deadlock

Avoid a deadlock with the r_serial thread waiting for
os_sync_lock in nfs4_get_otw_cred_by_osp() which might be
held by the nfs4close_otw thread. This thread would
wait in nfs4_attr_cache() for the completion of the r_serial
thread.

show more ...

7282 nlm_host leaks by nlm_host_findcreate() callers leads to hang in nlm_svc_stopping()

refs #3127

titanic_30: workaround for e1000g failover problem

When the problem is detected (see redmine #3100 and illumos #7190) rest
the adapter.

refs #3100

This commit fixes https://www.illumos.org/issues/6779.

Chronology of the events:

1. we have an empty directory
2. the filesystem is nearly out of quota
3. a snapshot prevents any space from being f

This commit fixes https://www.illumos.org/issues/6779.

Chronology of the events:

1. we have an empty directory
2. the filesystem is nearly out of quota
3. a snapshot prevents any space from being freed
4. a remote clients calls opendir via nfs4
5. the same client removes the directory
6. the client proceeds with readdir --> boom.

During 4, the client obtains a FH for the directory.
During 5, the directory entry gets removed, the inode is added to the
unlinked set and z_unlinked is set.
Then the inode contents is deleted (dmu_free_long_range).
Deletion of the inode itself fails because the fs ran out of space exactly
at this moment. The inode is left in the unlinked set, the znode is freed.
During 6, the readdir of the client instantiates a new znode for the (empty)
inode, this time with z_unlinked unset.
During zap read, the contents of the empty file is interpreted as a fatzap,
which leads to the crash.

This patch addresses the problem twofold:
1. when instantiating a znode, set z_unlinked when z_links == 0
2. mark the deletion of the inode as netfree (in zfs_rmnode).

refs #3026

show more ...

ZFS: vdev_avoid_read

Avoid reading from a disk if possible. This can be used during
resilver to avoid reading from a bad data disk, but leave it
in the pool for redundancy.
Configure via mdb:
::spa

ZFS: vdev_avoid_read

Avoid reading from a disk if possible. This can be used during
resilver to avoid reading from a bad data disk, but leave it
in the pool for redundancy.
Configure via mdb:
::spa -v to find the vdev
<vdev>::print -a vdev_avoid_read to get the address
<addr>/v 1 to set the feature

refs #3106

show more ...

7123 encode timestamps in rfs4_op_readdir()

7122 fix negative timestamps with nsec == 0 in nfs4_time_ntov()

zev: truncate offset fix

We range-lock the file now in zfs_freesp() until we've called the zev
callback to get rid of problems with inconsistent checksums due to
races between truncates.

Revert "zev: truncate offset"

This reverts commit a6c717764916afbde3e945c2d43764556a0ca299.

Will be replaced by another commit. This code
introduced a new deadlock when there is one truncate
thread

Revert "zev: truncate offset"

This reverts commit a6c717764916afbde3e945c2d43764556a0ca299.

Will be replaced by another commit. This code
introduced a new deadlock when there is one truncate
thread holding the znode lock and waiting for the
range lock and a zfs_remove() thread is holding the
range lock and is waiting for the znode lock in
zfs_link_destroy().

https://redmine.ob1.de/issues/3089

show more ...

nfssrv: don't hold exported_lock during compound processing

Instead rely on exi_hold/exi_rele the same way nfs3 does.

refs #3075

6940 Cannot unlink directories when over quota
Reviewed by: Dan McDonald <danmcd@omniti.com>
Reviewed by: Matthew Ahrens <mahrens@delphix.com>

zev: truncate offset

There is a race between truncate events. zev_get_checksums() relies on
a locked znode and their znode->z_size but this is not always consistant for
truncate events when there ar

zev: truncate offset

There is a race between truncate events. zev_get_checksums() relies on
a locked znode and their znode->z_size but this is not always consistant for
truncate events when there are multiple truncates running. The first
truncate may extend the size of a file and the second truncate could
shrink the file again. The first event would deliver a broken checksum.

We lock the znode for the whole operation now.

refs #2921

show more ...

6450 scrub/resilver unnecessarily traverses snapshots created after the scrub started
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Prakash Surya <prakash.surya@delphix.com>
Rev

6450 scrub/resilver unnecessarily traverses snapshots created after the scrub started
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Prakash Surya <prakash.surya@delphix.com>
Reviewed by: Richard Elling <Richard.Elling@RichardElling.com>
Approved by: Richard Lowe <richlowe@richlowe.net>

show more ...

6256 mptsas: deadlock in mptsas_handle_topo_change
Reviewed by: Rick McNeal <rick.mcneal@nexenta.com>
Reviewed by: Albert Lee <trisk@omniti.com>
Approved by: Dan McDonald <danmcd@omniti.com>

6267 dn_bonus evicted too early
Reviewed by: Richard Yao <ryao@gentoo.org>
Reviewed by: Xin LI <delphij@freebsd.org>
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Approved by: Richard Lowe <richl

6267 dn_bonus evicted too early
Reviewed by: Richard Yao <ryao@gentoo.org>
Reviewed by: Xin LI <delphij@freebsd.org>
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Approved by: Richard Lowe <richlowe@richlowe.net>

show more ...

6370 ZFS send fails to transmit some holes
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Chris Williamson <chris.williamson@delphix.com>

In certain circumstances, "zfs send -i" (inc

6370 ZFS send fails to transmit some holes
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Chris Williamson <chris.williamson@delphix.com>

In certain circumstances, "zfs send -i" (incremental send) can produce a
stream which will result in incorrect sparse file contents on the
target.

The problem manifests as regions of the received file that should be
sparse (and read a zero-filled) actually contain data from a file that
was deleted (and which happened to share this file's object ID).

Note: this can happen only with filesystems (not zvols, because they do
not free (and thus can not reuse) object IDs).

Note: This can happen only if, since the incremental source (FromSnap),
a file was deleted and then another file was created, and the new file
is sparse (i.e. has areas that were never written to and should be
implicitly zero-filled).

We suspect that this was introduced by 4370 (applies only if hole_birth
feature is enabled), and made worse by 5243 (applies if hole_birth
feature is disabled, and we never send any holes).

The bug is caused by the hole birth feature. When an object is deleted
and replaced, all the holes in the object have birth time zero. However,
zfs send cannot tell that the holes are new since the file was replaced,
so it doesn't send them in an incremental. As a result, you can end up
with invalid data when you receive incremental send streams. As a
short-term fix, we can always send holes with birth time 0 (unless it's
a zvol or a dataset where we can guarantee that no objects have been
reused).

Conflicts:

usr/src/test/zfs-tests/tests/functional/cli_root/zfs_receive/zfs_receive_010_pos.ksh

show more ...

zev: fix wrong return code in zev_get_checksums

Return EIO if offset > znode size instead of 0 (success)

zev: fix double free in zev_get_checksums()

this fix is related to https://redmine.ob1.de/issues/2920

further lint fixes

5780 Truncated coredumps (fix lint)

lint fixes

Workaround for 6395 cannot tune segkpsize up

zfs_remove: Always mark transactions as resulting in a net free of space

Otherwise we are not able to remove files when we are over quota due to
an EDQUOT from dsl_dir_tempreserve_impl().