64b5d74f | 25-Apr-2023 |
Dimitry Andric <dim@FreeBSD.org> |
zfs: make zfs_vfs_held() definition consistent with declaration
Noticed while attempting to change boolean_t into an actual bool: in include/sys/zfs_ioctl_impl.h, zfs_vfs_held() is declared to retur
zfs: make zfs_vfs_held() definition consistent with declaration
Noticed while attempting to change boolean_t into an actual bool: in include/sys/zfs_ioctl_impl.h, zfs_vfs_held() is declared to return a boolean_t, but in module/os/freebsd/zfs/zfs_ioctl_os.c it is defined to return an int. Make the definition match the declaration.
Obtained from: https://github.com/openzfs/zfs/commit/62cc9d4f6 Reviewed by: jhb MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D39753
show more ...
|
b0695c6a | 25-Apr-2023 |
Mateusz Guzik <mjg@FreeBSD.org> |
zfs: Revert "Fix data race between zil_commit() and zil_suspend()"
This reverts commit 4c856fb333ac57d9b4a6ddd44407fd022a702f00.
To quote a pending upstream PR: This reverts commit 4c856fb to resol
zfs: Revert "Fix data race between zil_commit() and zil_suspend()"
This reverts commit 4c856fb333ac57d9b4a6ddd44407fd022a702f00.
To quote a pending upstream PR: This reverts commit 4c856fb to resolve a newly introduced deadlock which in practice is more disruptive that the issue this commit intended to address.
Causes deadlocks described in https://github.com/openzfs/zfs/issues/14775
Sponsored by: Rubicon Communications, LLC ("Netgate")
show more ...
|
068913e4 | 17-Apr-2023 |
Pawel Jakub Dawidek <pjd@FreeBSD.org> |
zfs: Add vfs.zfs.bclone_enabled sysctl.
Keep block cloning disabled by default for now, but allow to enable and use it after setting vfs.zfs.bclone_enabled to 1, so people can easily try it.
Approv
zfs: Add vfs.zfs.bclone_enabled sysctl.
Keep block cloning disabled by default for now, but allow to enable and use it after setting vfs.zfs.bclone_enabled to 1, so people can easily try it.
Approved by: oshogbo Reviewed by: mm, oshogbo Differential Revision: https://reviews.freebsd.org/D39613
show more ...
|
1959e122 | 17-Apr-2023 |
Pawel Jakub Dawidek <pjd@FreeBSD.org> |
zfs: Merge https://github.com/openzfs/zfs/pull/14739
The zfs_log_clone_range() function is never called from the zfs_clone_range_replay() function, so I assumed it is safe to assert that zil_replayi
zfs: Merge https://github.com/openzfs/zfs/pull/14739
The zfs_log_clone_range() function is never called from the zfs_clone_range_replay() function, so I assumed it is safe to assert that zil_replaying() is never TRUE here. It turns out zil_replaying() also returns TRUE when the sync property is set to disabled.
Fix the problem by just returning if zil_replaying() returns TRUE.
Reported by: Florian Smeets Signed-off-by: Pawel Jakub Dawidek pawel@dawidek.net
Approved by: oshogbo, mm
show more ...
|
63ee747f | 15-Apr-2023 |
Mateusz Guzik <mjg@FreeBSD.org> |
zfs: Revert "ZFS_IOC_COUNT_FILLED does unnecessary txg_wait_synced()"
This reverts commit 519851122b1703b8445ec17bc89b347cea965bb9.
It results in data corruption, see: https://github.com/openzfs/zf
zfs: Revert "ZFS_IOC_COUNT_FILLED does unnecessary txg_wait_synced()"
This reverts commit 519851122b1703b8445ec17bc89b347cea965bb9.
It results in data corruption, see: https://github.com/openzfs/zfs/issues/14753
Sponsored by: Rubicon Communications, LLC ("Netgate")
show more ...
|
d012836f | 05-Apr-2023 |
Mateusz Guzik <mjg@FreeBSD.org> |
zfs: fix up EXDEV handling for clone_range
API contract requires VOPs to handle EXDEV internally, worst case by falling back to the generic copy routine. This broke with the recent changes.
While h
zfs: fix up EXDEV handling for clone_range
API contract requires VOPs to handle EXDEV internally, worst case by falling back to the generic copy routine. This broke with the recent changes.
While here whack custom loop to lock 2 vnodes with vn_lock_pair, which provides the same functionality internally. write start/finish around it plays no role so got eliminated.
One difference is that vn_lock_pair always takes an exclusive lock on both vnodes. I did not patch around it because current code takes an exclusive lock on the target vnode. zfs supports shared-locking for writes, so this serializes different calls to the routine as is, despite range locking inside. At the same time you may notice the source vnode can get some traffic if only shared-locked, thus once more this goes the safer route of exclusive-locking. Note this should be patched to use shared-locking for both once the feature is considered stable.
Technically the switch to vn_lock_pair should be a separate change, but it would only introduce churn immediately whacked by the rest of the patch.
[note: technically the review is still in progress, but so is the active breakage]
Sponsored by: Rubicon Communications, LLC ("Netgate")
show more ...
|