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 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
>
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