From: Chris Mason <chris.mason@oracle.com>
To: David Nicol <davidnicol@gmail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [RFC] proposal for a btrfs filesystem layout
Date: Mon, 23 Nov 2009 20:26:08 -0500 [thread overview]
Message-ID: <20091124012608.GF24068@think> (raw)
In-Reply-To: <934f64a20911201205j70b5b9cfm40260a4a3a6c7b0b@mail.gmail.com>
On Fri, Nov 20, 2009 at 02:05:11PM -0600, David Nicol wrote:
> On Fri, Nov 20, 2009 at 1:50 PM, Chris Mason <chris.mason@oracle.com>=
wrote:
> > COW semantics require touching btree nodes all the way up to the ro=
ot of
> > the btree, but this is different from the directory. =A0Directories=
are
> > stored in the btree, but you won't have to touch more than 8 or so =
btree
> > levels regardless of how deep your directory tree is.
> >
> > -chris
>=20
> Thanks for straightening me out on that point.
>=20
> Still, 8 might be a lot.
>=20
> Regardless of the decoupling of btrees and directories, am I right in
> thinking that mounted subvolumes instead of directories would (1)
> reduce contention
It might, it depends on the workload. But yes, one point of big
contention is the root node of the btree and each subvolume has its own
root.
> (2) reduce the number of levels touched since number
> of levels is a function of the number of fs entities in the volume,
> therefore
It depends on the overall btree size. Probably.
> (3) defining a file system entity that transparently becomes
> a mounted subvolume (by transparently I mean without an additional
> mount command) and (4) crafting a utility to streamline
> creation-and-implied-mounting of the entity type from #3 would make
> sense?
Sure. It definitely makes sense to explore the subvolume and
snapshotting user interfaces.
-chris
--
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:[~2009-11-24 1:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-20 18:50 [RFC] proposal for a btrfs filesystem layout Goffredo Baroncelli
2009-11-20 19:24 ` David Nicol
2009-11-20 19:50 ` Chris Mason
2009-11-20 20:05 ` David Nicol
2009-11-24 1:26 ` Chris Mason [this message]
2009-11-20 19:54 ` Chris Mason
2009-11-20 23:31 ` Goffredo Baroncelli
2009-11-24 1:27 ` Chris Mason
-- strict thread matches above, loose matches on Subject: below --
2009-11-24 18:27 Goffredo Baroncelli
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=20091124012608.GF24068@think \
--to=chris.mason@oracle.com \
--cc=davidnicol@gmail.com \
--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 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.