Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: System/single + Metadata/single as leftover cruft of mkfs?
Date: Fri, 5 Dec 2014 06:57:55 +0000 (UTC)	[thread overview]
Message-ID: <pan$e8a0d$4c65d3df$b96b30fa$cda09308@cox.net> (raw)
In-Reply-To: 54806C19.4090503@gmail.com

Austin S Hemmelgarn posted on Thu, 04 Dec 2014 09:13:45 -0500 as
excerpted:

> Also, for future reference, you can use the switch -mprofiles=single to
> just balance out those chunks.

FWIW, the way I do it has the same effect on those left-over chunks, but 
uses a slightly different method and may be a bit more useful:

-musage=0

And to get rid of the single data chunk as well since I normally use 
raid1 for both data and metadata:

-dusage=0

Of course they can be combined in the same balance command.


This approach rebalances only those chunks with zero usage.  Since they 
have no usage, they aren't rewritten, simply deleted.

Of course that removes the empty single-profile chunks, but on systems 
with usage over a longer period, either where the filesystem was filled 
before the command was run or when the command was run for this reason 
instead of the single-profile chunks reason, there may be additional 
empty chunks of the desired profile (raid1 in my case).  Removing these 
empty chunks by rebalancing only them is a very quick way to return their 
allocation to unallocated space, thus freeing them for allocation on 
demand as either data or metadata, instead of keeping them pinned as one 
or the other which is what an empty chunk is effectively doing.

Of course on the most recent kernels (I think only 3.18 has it and of 
course it's not yet released tho the release is getting close) that's 
less of an issue since the kernel will now rebalance when data/metadata 
chunk usage gets too unbalanced, but previous to that, a bunch of empty 
data chunks hogging all the space so no more chunks could be allocated, 
while metadata was full and a new metadata chunk was needed, was a 
relatively common ENOSPC trigger, and the reverse (empty or nearly empty 
metadata chunks hogging all the otherwise free space, a new data chunk 
needed), while rarer, was known to happen on occasion as well.

But at least until that new auto-rebalancer has a bit more testing, 
knowing how to rebalance empty chunks and thus eliminate them, especially 
when a balance to free up space is otherwise unable to run due to no free 
space to allocate a new chunk to write the partial chunks into, can come 
in handy. =:^)

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


  parent reply	other threads:[~2014-12-05  6:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-04 13:53 System/single + Metadata/single as leftover cruft of mkfs? Shriramana Sharma
2014-12-04 14:13 ` Austin S Hemmelgarn
2014-12-04 14:22   ` Austin S Hemmelgarn
2014-12-04 14:25   ` Shriramana Sharma
2014-12-04 14:36     ` Austin S Hemmelgarn
2014-12-04 18:17     ` Robert White
2014-12-04 23:55       ` Shriramana Sharma
2014-12-05  6:57   ` Duncan [this message]
2014-12-04 18:32 ` Goffredo Baroncelli
2014-12-08  1:22   ` Qu Wenruo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='pan$e8a0d$4c65d3df$b96b30fa$cda09308@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox