On Tue, Jan 12, 2010 at 12:27 PM, jim owens <jowens@xxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
