Re: New disk format pushed out

Gabor MICSKO
2008-12-09T07:52:12Z

As i see the standalone kernel module git repo not updated. Will it be
updated too?

http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-unstable-standalone.git;a=summary

On Mon, 2008-12-08 at 19:13 -0500, Chris Mason wrote:
> Hello everyone,
>
> I've pushed out most of the pending patches, including a few big disk
> format changes. It includes Yan Zheng's super block duplication code
> (with a few small mods for performance) and all new data checksumming
> code.
>
> The data checksumming is a big change, so I'll paste in the changeset
> description here.
>
> Btrfs stores checksums for each data block. Until now, they have
> been stored in the subvolume trees, indexed by the inode that is
> referencing the data block. This means that when we read the inode,
> we've probably read in at least some checksums as well.
>
> But, this has a few problems:
>
> * The checksums are indexed by logical offset in the file. When
> compression is on, this means we have to do the expensive checksumming
> on the uncompressed data. It would be faster if we could checksum
> the compressed data instead.
>
> * If we implement encryption, we'll be checksumming the plain text and
> storing that on disk. This is significantly less secure.
>
> * For either compression or encryption, we have to get the plain text
> back before we can verify the checksum as correct. This makes the raid
> layer balancing and extent moving much more expensive.
>
> * It makes the front end caching code more complex, as we have touch
> the subvolume and inodes as we cache extents.
>
> * There is potentitally one copy of the checksum in each subvolume
> referencing an extent.
>
> The solution used here is to store the extent checksums in a dedicated
> tree. This allows us to index the checksums by phyiscal extent
> start and length. It means:
>
> * The checksum is against the data stored on disk, after any compression
> or encryption is done.
>
> * The checksum is stored in a central location, and can be verified without
> following back references, or reading inodes.
>
> This makes compression significantly faster by reducing the amount of
> data that needs to be checksummed. It will also allow much faster
> raid management code in general.
>
> The checksums are indexed by a key with a fixed objectid (a magic value
> in ctree.h) and offset set to the starting byte of the extent. This
> allows us to copy the checksum items into the fsync log tree directly (or
> any other tree), without having to invent a second format for them.
>
> -chris
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html