From: Martin Steigerwald <Martin@lichtvoll.de>
To: Hugo Mills <hugo@carfax.org.uk>,
Sergei Trofimovich <slyich@gmail.com>,
linux-btrfs@vger.kernel.org
Subject: Re: speeding up slow btrfs filesystem
Date: Sat, 17 Dec 2011 12:57:32 +0100 [thread overview]
Message-ID: <201112171257.33141.Martin@lichtvoll.de> (raw)
In-Reply-To: <20111217114508.GE17573@carfax.org.uk>
Am Samstag, 17. Dezember 2011 schrieb Hugo Mills:
> > > The metadata trees are automatically balanced, simply by the
> > >nature
> > >
> > > of the B-tree algorithms used. Balance won't, in general, affect
> > > them. The only thing that a balance will achieve on a single-disk
> > > filesystem is to reclaim unused space from allocated block groups
> > > -- so the "total" value in your Data and Metadata entries below
> > > will go down.
> >
> >
> >
> > But thats only for optical viewing pleasure as far as I understood
> > you?
> >
> >
> >
> > Only if there would be not enough free space for one tree to extend
> > then a balance would make sense? I.e. when I had a lot of metadata
> > so that the metadata would need to extend (which seems unlikely
> > given below figures).
>
> From the context, I think you're misusing the term "tree" here to
> mean "block group type" (i.e. data or metadata).
>
> That aside, though, yes, you're right, it's effectively only
> cosmetic -- although it can be useful if you have a fully-allocated
> filesystem where (for example) data is full and there's lots of
> metadata space free, and you want to write more data. In that case,
> the FS wants to allocate another Data block group, but can't because
> there's no raw storage left to allocate from, despite there being lots
> of free space in the allocated Metadata block groups. A balance in
> that case would free up some of the metadata block groups and allow
> that space to be reallocated as data. (I think it tries to do this
> anyway, but I'm not 100% sure about that).
Okay, thats the more likely case then ;).
Thanks for clearing that up,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
next prev parent reply other threads:[~2011-12-17 11:57 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-16 17:51 speeding up slow btrfs filesystem Martin Steigerwald
2011-12-16 17:54 ` Martin Steigerwald
2011-12-16 18:38 ` Goffredo Baroncelli
2011-12-16 19:53 ` Martin Steigerwald
2011-12-16 20:58 ` Martin Steigerwald
2011-12-17 7:03 ` Sergei Trofimovich
2011-12-17 11:09 ` Martin Steigerwald
2011-12-17 11:26 ` Hugo Mills
2011-12-17 11:38 ` Martin Steigerwald
2011-12-17 11:45 ` Hugo Mills
2011-12-17 11:57 ` Martin Steigerwald [this message]
2011-12-17 16:35 ` Martin Steigerwald
2011-12-17 17:27 ` Hugo Mills
2011-12-17 11:39 ` Goffredo Baroncelli
2011-12-18 18:41 ` Andrea Gelmini
2011-12-20 19:46 ` Goffredo Baroncelli
2011-12-17 11:11 ` Chris Samuel
2011-12-17 12:00 ` Martin Steigerwald
2011-12-17 12:42 ` David McBride
2011-12-17 16:14 ` Martin Steigerwald
-- strict thread matches above, loose matches on Subject: below --
2011-12-17 11:54 Martin Steigerwald
2011-12-17 12:02 ` Martin Steigerwald
2011-12-17 12:50 ` Goffredo Baroncelli
2011-12-17 16:10 ` Martin Steigerwald
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=201112171257.33141.Martin@lichtvoll.de \
--to=martin@lichtvoll.de \
--cc=hugo@carfax.org.uk \
--cc=linux-btrfs@vger.kernel.org \
--cc=slyich@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.