On 12/11/2014 11:53 AM, Duncan wrote:
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.
Thanx Duncan, I tried the old manual method. It works well to me. Will
try the new kernel later.
--
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
