linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anand Jain <Anand.Jain@oracle.com>
To: Calvin Walton <calvin.walton@kepstin.ca>
Cc: Roman Mamedov <rm@romanrm.ru>, linux-btrfs@vger.kernel.org
Subject: Re: Massive metadata size increase after upgrade from 3.2.18 to 3.4.1
Date: Wed, 13 Jun 2012 18:30:40 +0800	[thread overview]
Message-ID: <4FD86BD0.5090606@oracle.com> (raw)
In-Reply-To: <1339522697.2990.10.camel@ayu>


  Did you try balance ? (also there is a balance option
  to pick the least utilized metadata chunks).

  in long run when you have the understanding of your
  files and sizes tuning using mount option metadata_ratio
  might help.

  but not sure how the  metadata expanded to 84.38G
  was there any major delete operation on the filesystem?

thanks, Anand
   

On 13/06/12 01:38, Calvin Walton wrote:
> On Sat, 2012-06-09 at 01:38 +0600, Roman Mamedov wrote:
>> Hello,
>>
>> Before the upgrade (on 3.2.18):
>>
>> Metadata, DUP: total=9.38GB, used=5.94GB
>>
>> After the FS has been mounted once with 3.4.1:
>>
>> Data: total=3.44TB, used=2.67TB
>> System, DUP: total=8.00MB, used=412.00KB
>> System: total=4.00MB, used=0.00
>> Metadata, DUP: total=84.38GB, used=5.94GB
>>
>> Where did my 75 GB of free space just went?
>
> Btrfs tries to keep a certain ratio of allocated data space to allocated
> metadata space at all times, in order to ensure that there is always
> some free metadata space available. In 3.3 (I believe, but haven't
> actually checked...) this ratio was increased, since people were still
> complaining about btrfs reporting out of space errors too soon.
>
> On a filesystem containing (a relatively small number of) large files,
> it probably over-allocates the metadata space, which is what you're
> seeing. I'm not sure if the ratio is tunable.
>
> But better to have a bit of unused metadata space than to get 'out of
> space' errors once you've filled your disk and you're trying to delete
> some files!
>

  reply	other threads:[~2012-06-13 10:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-08 19:38 Massive metadata size increase after upgrade from 3.2.18 to 3.4.1 Roman Mamedov
2012-06-12 17:38 ` Calvin Walton
2012-06-13 10:30   ` Anand Jain [this message]
2012-06-14 11:33 ` David Sterba
2012-06-17 15:29   ` Roman Mamedov

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=4FD86BD0.5090606@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=calvin.walton@kepstin.ca \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=rm@romanrm.ru \
    /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;
as well as URLs for NNTP newsgroup(s).