Re: [PATCH] Btrfs: get more accurate output in fd command.

[Dongsheng Yang <yangds.fnst@cn.fujitsu.com>]

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.
>