Metadata Duplication on a Single Disk Btrfs Setup

Metadata Duplication on a Single Disk Btrfs Setup

[Mitch Harder]

On a single disk btrfs setup, such as for a desktop computer, what are
the implecations of creating your btrfs partition with '-m single'?

At first, I assumed I would want a single disk desktop setup to be
configured as 'single'.  But that may not be the case for metadata.

I see that the default is for metadata duplication in a single disk scenario.

Is duplication of the metadata important for recovery from common
desktop user problems such as power interruption?

Re: Metadata Duplication on a Single Disk Btrfs Setup

[jim owens]

Mitch Harder wrote:
> On a single disk btrfs setup, such as for a desktop computer, what are
> the implecations of creating your btrfs partition with '-m single'?
> 
> At first, I assumed I would want a single disk desktop setup to be
> configured as 'single'.  But that may not be the case for metadata.
> 
> I see that the default is for metadata duplication in a single disk scenario.
> 
> Is duplication of the metadata important for recovery from common
> desktop user problems such as power interruption?

Duplication of metadata protects against unreadable disk blocks
or disk blocks that have garbage written in them. Power interruption
can cause that in rare cases (and on some hardware not so rare).

The more usual power loss issue is incomplete or stale data.  Even
single metadata mode should protect from that.

So the short answer is it provides some additional protection
at the expense of more space used.  How much you need that extra
protection depends on your hardware, power reliability, and how
valuable your data is.

jim

Re: Metadata Duplication on a Single Disk Btrfs Setup

[Mitch Harder]

On Tue, Jan 12, 2010 at 12:27 PM, jim owens <jowens@hp.com> wrote:
> Mitch Harder wrote:
>> On a single disk btrfs setup, such as for a desktop computer, what a=
re
>> the implecations of creating your btrfs partition with '-m single'?
>>
>> At first, I assumed I would want a single disk desktop setup to be
>> configured as 'single'. =A0But that may not be the case for metadata=
=2E
>>
>> I see that the default is for metadata duplication in a single disk =
scenario.
>>
>> Is duplication of the metadata important for recovery from common
>> desktop user problems such as power interruption?
>
> Duplication of metadata protects against unreadable disk blocks
> or disk blocks that have garbage written in them. Power interruption
> can cause that in rare cases (and on some hardware not so rare).
>
> The more usual power loss issue is incomplete or stale data. =A0Even
> single metadata mode should protect from that.
>
> So the short answer is it provides some additional protection
> at the expense of more space used. =A0How much you need that extra
> protection depends on your hardware, power reliability, and how
> valuable your data is.
>
> jim
>

To satisfy my curiosity, I did a series of kernel compilation
comparisons on freshly formatted partitions with and without '-m
single -d single', and with and without compression.  I also added in
a control run on the same partition with default ext4 formatting.

I did not see much difference between the disk usage when disabling
metadata duplication.

I was also surprised to see so little difference in compile time
between the different cases.  I guess most of the files remained in
cache.

Here's a summary of my results:

Case #1: Ext4 control case
Case #2: Btrfs (mkfs defaults, no compression)
Case #3: Btrfs (Single metadata (& data), no compression)
Case #4: Btrfs (mkfs defaults, with compression)
Case #5: Btrfs (Single metadata (& data), with compression)

Case          (time make -j3)     1k blocks Used
Case #1        24m45.857s           1370140
Case #2        24m49.270s           1182080
Case #3        24m47.637s           1181932
Case #4        24m54.318s            477592
Case #5        24m54.720s            477744
--
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