I am trying to understand how exactly the file extent back references
work in btrfs. Can please someone tell me if the following is correct? -
The back references are accumulated in an in-memory balanced tree
(delayed-ref.c and delayed-ref.h) and pushed to disk during the
transaction commit (a part of a checkpoint). They are placed into the
B-tree under the key (bytenr, BTRFS_EXTENT_REF_KEY, hash of the four
fields of the record), so that they are stored next to the file extent
forward references.
I am also wondering about the implications of copy on write: Imagine
that you have an inode with four file extents and thus also four back
references. COW of one of the extents then causes the COW of the inode.
The new version of the inode has a different transaction ID, which is
also one of the fields of back reference records. This causes the file
system to add four new back reference records - one for the modified
extent and three for the unmodified ones (since the transaction ID field
has to be updated). Does this really happen, or is there some scheme to
avoid adding these extra records?
Thank you,
Peter Macko
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html