Skip to Content
Last modified by Drunk Monkey on 2024-09-01 12:08
From version 1.4
edited by Drunk Monkey
on 2024-09-01 12:07
Change comment: There is no comment for this version
To version 2.1
edited by Drunk Monkey
on 2024-09-01 12:08
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -22,9 +22,7 @@
22 22  
23 23  This uber block is responsible for verifying the integrity of the entire Merkle tree. If a data block changes, all the parent hash blocks should change as well, including the uber block. If at any point, a hash does not match its corresponding children, we have inconsistencies in the tree or data corruption.
24 24  
25 -[[image:hash-tree.png]]
26 -
27 -[[image:https://web.archive.org/web/20210430213506im_/http://pthree.org/wp-content/uploads/2012/12/hash-tree.png||alt="Image showing an example of our binary hash tree."]]
25 +[[image:hash-tree.png||alt="Image showing an example of our binary hash tree."]]
28 28  //Image showing our binary hash tree example//
29 29  
30 30  ZFS uses a Merkle tree to verify the integrity of the entire filesystem and all of the data stored in it. When you scrub your storage pool, ZFS is verifying every SHA-256 hash in the Merkle tree to make sure there is no corrupted data. If there is redundancy in the storage pool, and a corrupted data block is found, ZFS will look elsewhere in the pool for a good data block at the same location by using these hashes. If one is found, it will use that block to fix the corrupted one, then reverify the SHA-256 hash in the Merkle tree.
... ... @@ -37,9 +37,7 @@
37 37  
38 38  In the following image, when a data block is updated, the hash tree must also be updated. All hashes starting with the child block, and all its parent nodes must be updated with the new hash. The yellow blocks are a copy of the data, elsewhere on the filesystem, and the parent hash nodes are updated to point to the new block locations.
39 39  
40 -[[image:copy-on-write.png]]
41 -
42 -[[image:https://web.archive.org/web/20210430213506im_/http://pthree.org/wp-content/uploads/2012/12/copy-on-write.png||alt="Image showing the nature of updating the hash tree when a data block is updated."]]
38 +[[image:copy-on-write.png||alt="Image showing the nature of updating the hash tree when a data block is updated."]]
43 43  //Image showing the COW model when a data block is created, and the hash tree is updated. Courtesy of [[dest-unreachable.net>>url:https://web.archive.org/web/20210430213506/http://wiki.dest-unreachable.net/display/ZFS/Copy+On+Write]]//.
44 44  
45 45  As mentioned, COW heavily fragments the disk. This can have massive performance impacts. So, some work needs to be taken to allocate blocks in advance to minimize fragmentation. There are two basic approaches: using a b-tree to pre-allocate extents, or using a slab approach, marking slabs of disk for the copy. ZFS uses the slab approach, where Btrfs uses the b-tree approach.