4f23c764 | 08-Jul-2016 |
Arne Jansen <jansen@webgods.de> |
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
(cherry picked from commit 67738a4fd5331c5c62b9fead7a7739afa2476cf9)
show more ...
|
a7e4abc5 | 30-Jun-2016 |
Arne Jansen <jansen@webgods.de> |
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
(cherry picked from commit c3a1418d1a4c19d574cfbf275daf91a0d44b7340)
show more ...
|
70164074 | 11-Oct-2015 |
Justin T. Gibbs <gibbs@FreeBSD.org> |
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>
(cherry picked from commit 1666a561bcf7351b8aa2b813412d0e84137a21b0)
show more ...
|
ee88b7a2 | 22-Oct-2015 |
Paul Dagnelie <pcd@delphix.com> |
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
(cherry picked from commit b69b4dd002eeedb732d8b47b06637354a47a49e2)
show more ...
|
8f9b66cc | 14-Oct-2015 |
Simon Klinkert <klinkert@webgods.de> |
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().
(cherry p
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().
(cherry picked from commit da84684dce7fe256d1b303e0b162dea06bb2e095)
show more ...
|
1b1b8823 | 08-Sep-2015 |
Arne Jansen <sensille@gmx.net> |
6220 memleak in l2arc on debug build Reviewed by: Saso Kiselkov <saso.kiselkov@nexenta.com> Reviewed by: Simon Klinkert <simon.klinkert@gmail.com> Reviewed by: George Wilson <george@delphix.com> Appr
6220 memleak in l2arc on debug build Reviewed by: Saso Kiselkov <saso.kiselkov@nexenta.com> Reviewed by: Simon Klinkert <simon.klinkert@gmail.com> Reviewed by: George Wilson <george@delphix.com> Approved by: Robert Mustacchi <rm@joyent.com>
(cherry picked from commit 8dd201a56d9303c33e56b2cb18574069391f55d6)
show more ...
|