On Tue, Jan 12, 2010 at 12:27 PM, jim owens jow...@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 #124m45.857s 1370140
Case #224m49.270s 1182080
Case #324m47.637s 1181932
Case #424m54.318s477592
Case #524m54.720s477744
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
