summaryrefslogtreecommitdiffstats
path: root/config/kernel-blk-queue-physical-block-size.m4
diff options
context:
space:
mode:
authorMatthew Ahrens <[email protected]>2014-09-12 05:28:35 +0200
committerBrian Behlendorf <[email protected]>2014-10-21 15:26:50 -0700
commit6c59307a3c52535513e1ea3b612dac5a594c5b5d (patch)
tree354e056c4e1bfca9feafc741cb6d5e3b775cf77b /config/kernel-blk-queue-physical-block-size.m4
parent356d9ed4c81dbb1c52627d1af242f4d9f66b67af (diff)
Illumos 3693 - restore_object uses at least two transactions to restore an object
Restore_object should not use two transactions to restore an object: * one transaction is used for dmu_object_claim * another transaction is used to set compression, checksum and most importantly bonus data * furthermore dmu_object_reclaim internally uses multiple transactions * dmu_free_long_range frees chunks in separate transactions * dnode_reallocate is executed in a distinct transaction The fact the dnode_allocate/dnode_reallocate are executed in one transaction and bonus (re-)population is executed in a different transaction may lead to violation of ZFS consistency assertions if the transactions are assigned to different transaction groups. Also, if the first transaction group is successfully written to a permanent storage, but the second transaction is lost, then an invalid dnode may be created on the stable storage. 3693 restore_object uses at least two transactions to restore an object Reviewed by: Christopher Siden <[email protected]> Reviewed by: George Wilson <[email protected]> Reviewed by: Andriy Gapon <[email protected]> Approved by: Robert Mustacchi <[email protected]> Original authors: Matthew Ahrens and Andriy Gapon References: https://www.illumos.org/issues/3693 https://github.com/illumos/illumos-gate/commit/e77d42e Ported by: Turbo Fredriksson <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #2689
Diffstat (limited to 'config/kernel-blk-queue-physical-block-size.m4')
0 files changed, 0 insertions, 0 deletions