public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
* New disk format pushed out
@ 2008-12-09  0:13 Chris Mason
  2008-12-09  7:52 ` Gabor MICSKO
  2008-12-09 12:23 ` Chris Mason
  0 siblings, 2 replies; 6+ messages in thread
From: Chris Mason @ 2008-12-09  0:13 UTC (permalink / raw)
  To: linux-btrfs

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



^ permalink raw reply	[flat|nested] 6+ messages in thread
* New disk format pushed out
@ 2008-12-02 15:29 Chris Mason
  0 siblings, 0 replies; 6+ messages in thread
From: Chris Mason @ 2008-12-02 15:29 UTC (permalink / raw)
  To: linux-btrfs

Hello everyone,

I've pushed out Josef's updates to make the checksum selectable at mkfs
time (right now there's only one choice, but we now have the disk format
bits for more).

This means both kernel and progs have a new disk format.  The format
will change a few more times this week as we try to hammer out the 1.0
format.

-chris




^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2008-12-11  2:01 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-12-09  0:13 New disk format pushed out Chris Mason
2008-12-09  7:52 ` Gabor MICSKO
2008-12-09 11:43   ` Chris Mason
2008-12-09 12:23 ` Chris Mason
2008-12-11  2:01   ` Chris Mason
  -- strict thread matches above, loose matches on Subject: below --
2008-12-02 15:29 Chris Mason

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox