From: Arne Jansen <sensille@gmx.net>
To: Peeters Simon <peeters.simon@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: [patch] Move nodesize/leafsize/sectorsize to fs_info
Date: Wed, 26 Oct 2011 16:47:15 +0200 [thread overview]
Message-ID: <4EA81D73.8090005@gmx.net> (raw)
In-Reply-To: <20111026133409.GA5914@twin.jikos.cz>
On 10/26/2011 03:34 PM, David Sterba wrote:
> Hi,
>
> sorry for late reply. This patch tries to unify node-/leaf-/... sizes
> nad put it just into fs_info, but this assumes all trees share the same
> sizes. Unfortunatelly this is not true (once we allow big blocks; soon?).
>
> The root tree has a hardcoded size of 4k, see the __setup_root called
> with 4k in open_ctree:
>
> 1760 __setup_root(4096, 4096, 4096, 4096, tree_root,
> 1761 fs_info, BTRFS_ROOT_TREE_OBJECTID);
>
> the other trees have size defined during mkfs. And only these trees
> share the size. You'd have to add exception to use 4k or ->leafsize
> depending on the tree being used. It's less error prone to always just
> the structure item as it will hold always the correct value, although
> there is some memory wasted.
The sizes get initialized to 4096, but after the super block is read,
these are replaced by those from the SB.
>
> From the peformace POV, the ->leafsize etc items can cause cacheline
> bouncing when any of the code wants to access the item (and it's not
> that rare) for a different tree / cpu. But anyway with current
> performance status, this effect will be hardly measurable.
>
> On Sun, Aug 07, 2011 at 11:54:31PM +0200, Peeters Simon wrote:
>> [1] https://btrfs.wiki.kernel.org/index.php/Cleanup_ideas
>
> I'd like to see how this idea was expected to be implemented, but
> there's no wiki to check.
It was indeed meant to get rid of the possibility to have different
sizes for different trees, as it just adds complexity. Chris mentioned
once that he does not intend to allow different sizes between trees,
thus the idea for this cleanup.
-Arne
>
>
> david
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-10-26 14:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-07 21:54 [patch] Move nodesize/leafsize/sectorsize to fs_info Peeters Simon
2011-10-26 13:34 ` David Sterba
2011-10-26 14:47 ` Arne Jansen [this message]
2011-10-26 16:23 ` David Sterba
2011-10-26 16:27 ` Chris Mason
2011-10-26 20:54 ` Arne Jansen
2011-10-31 13:51 ` David Sterba
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=4EA81D73.8090005@gmx.net \
--to=sensille@gmx.net \
--cc=linux-btrfs@vger.kernel.org \
--cc=peeters.simon@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 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).