Dongsheng Yang posted on Wed, 10 Dec 2014 23:02:15 +0800 as excerpted: >> And in the example, the mkfs was supplied with two devices, so there's >> no dup metadata remaining from a formerly single-device filesystem, >> either. (Tho there will be the small single-mode stubs, empty, >> remaining from the mkfs process, as no balance has been run to delete >> them yet, but those are much smaller and empty.) > > Yes. One question not related here: how about delete them in the end of > mkfs? GB covered the old, manual balance method. Do a btrfs balance -dusage=0 -musage=0 (or whatever, someone posted his recipe doing the same thing except with the single profiles instead of zero usage), and those stubs should disappear, as they're empty so there's nothing to rewrite when the balance does its thing and it simply removes them. FWIW I actually have a mkfs helper script here that takes care of a bunch of site-default options such as dual-device raid1 both data/metadata, skinny-metadata, etc, and it actually prompts for a mountpoint (assuming it's already setup in fstab) and will do an immediate mount and balance usage=0 to eliminate the stubs if that mountpoint is filled in, again assuming it appears in fstab as well. Since I keep fully separate filesystems to avoid putting all my data eggs in the same not-yet-fully- stable btrfs basket, and my backup system includes periodically blowing away the backup and (after booting to the new backup) the working copy with a fresh mkfs for a clean start, the mkfs helper script is useful, and since I was already doing that, it was reasonably simple to extend it to handle the mount and stub-killing balance immediately after the mkfs. But at least in theory, that old manual method shouldn't be necessary with a current (IIRC 3.18 required) kernel, since btrfs should now automatically detect empty chunks and automatically rebalance to remove them as necessary. However, I've been busy and haven't actually tried 3.18 yet, and thus obviously haven't done a mkfs and mount of a fresh filesystem to see how long it actually takes to trigger and remove those stubs, so for all I know it takes awhile to kick in, and if people are bothered by the display of the stubs before it does, they can of course still do it the old way. -- 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
