Rich Freeman posted on Tue, 21 Oct 2014 12:40:01 -0400 as excerpted: > On Tue, Oct 21, 2014 at 5:29 AM, Duncan <1i5t5.dun...@cox.net> wrote: >> David Sterba posted on Mon, 20 Oct 2014 18:34:03 +0200 as excerpted: >> >>> On Thu, Oct 16, 2014 at 01:33:37PM +0200, David Sterba wrote: >>>> I'd like to make it default with the 3.17 release of btrfs-progs. >>>> Please let me know if you have objections. >>> >>> For the record, 3.17 will not change the defaults. The timing of the >>> poll was very bad to get enough feedback before the release. Let's >>> keep it open for now. >> >> FWIW my own results agree with yours, I've had no problem with skinny- >> metadata here, and it has been my default now for a couple >> backup-and-new- >> mkfs.btrfs generations, now. >> >> > How does one enable it for an existing filesystem? Is it safe to just > run btrfstune -x? Can this be done on a mounted filesystem? Are there > any risks with converting?
AFAIK, enabling skinny-metadata with btrfstune simply enables it for future metadata commits. It doesn't change existing metadata. However, with skinny-metadata enabled, doing a balance start -m will rewrite existing metadata, thus converting it to skinny if it wasn't skinny before. Since the kernel has code for both "fat" metadata and skinny-metadata, they can exist side-by-side and the kernel will use whichever code is appropriate. And since (afaik) a balance effects conversion of existing metadata by simply rewriting it using the same metadata writing paths it'd normally use only now on the skinny-metadata side, there should be no additional risk to that, either. The narrow-case additional risk there is would be due to the fact that the code paths are different, and while both paths have been well exercised by now with no bugs related to those specific code paths in awhile, in theory anyway, it's narrowly possible that an individual installation's use-case and data happened to work just fine on the available metadata, but will trigger some exotic and as yet unseen bug when you switch to skinny-metadata and thus exercise the other code- path. I'd call the risk of that nonzero but extremely unlikely. IOW, if you're familiar with Douglas Adams' Hitchhiker's Guide series, it's almost the kind of probability that you'd need an improbability drive to hit. =:^) If not, compare it to winning the lottery or getting struck by lightening, yes, people do sometimes do it, but it's not something you should plan your life around, particularly if you aren't in the habit of playing golf and sticking a club in the air, in the middle of a lightning storm! =:^) And if you're adverse to that sort of odds, why are you playing with still not entirely stable btrfs at this point, anyway? As for the mounted filesystem question, since all it does is flip a switch so that new metadata writes use the skinny-metadata code path, it shouldn't be a problem. However, I'd probably do it on an unmounted filesystem here, simply because there's no reason to tempt fate... unless your goal is to see what happens, of course. =:^) Matter of fact, personally, since I tend to periodically backup, do a fresh mkfs.btrfs with the new features I want enabled, and restore, I've never actually used btrfstune for this myself, either. But that's more a matter of that being the most convenient time to switch it over since I'm already doing the fresh mkfs anyway, than because I'm being overly cautious. Still, for those with a similar btrfs rotation system already in place, why tempt fate, unless of course your whole /object/ is a deliberate test and tempt of fate? BTW... @ Dave Sterba: I'm running no-holes too, and haven't had problems with it either, tho it's obviously a bit newer and doesn't yet have the degree of testing that skinny-metadata has. Any idea when that'll go default? It's probably best to stagger them, which probably means default no-holes for the 3.19 userspace release since default skinny-metadata is presumably going to be 3.18 now; does that sound about right? -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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
