From: Josef Bacik <jbacik@fusionio.com>
To: Jerome Haltom <wasabi@cogito.cx>
Cc: Chris Murphy <lists@colorremedies.com>,
Hugo Mills <hugo@carfax.org.uk>,
Gabriel de Perthuis <g2p.code@gmail.com>,
Linux Btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Q: Why subvolumes?
Date: Tue, 23 Jul 2013 21:27:37 -0400 [thread overview]
Message-ID: <20130724012737.GB30875@localhost.localdomain> (raw)
In-Reply-To: <CA+V+5QoSFZOc_nekBUQQSQo+wn5mNaqJNDuq=kwU23a01Nn1Kw@mail.gmail.com>
On Tue, Jul 23, 2013 at 06:39:57PM -0500, Jerome Haltom wrote:
> Yeah. I was merely curious about the architecture limits that drove
> the design this way, to begin with. Mostly because it seems "odd". It
> seems like the most obvious and most natural thing from the user's
> perspective to do would just be able to reflink directories. Like
> every decent source control system that exists, for instance. So, I
> figured there must be some very good reason it wasn't done like that.
>
> I'm still not completely sure what that very good reason is. Obviously
> whatever structure that currently exists for subvolumes would need to
> continue existing, to begin a unique inode scope. But, since
> apparently the VFS can be instructed to plop a new dev_id anywhere in
> the hierarchy, I I still don't see why explicit subvolumes are
> required. Seems more natural to be able to put a quota on a directory.
> To be able to set raid policy on a directory. Compression on a
> directory. COW semantics on a directory. Etc.
>
> Ahh well, some of you gave really nice detailed answers, and I
> appreciate that. Thanks.
>
Subvolumes are described as directories simply to make it easier to understand.
Directories do not change the heirarchy within the file system itself, they are
simply items in the btree like anything else, they are not special at all.
Subvolumes are _represented_ as directories, but really the directories are just
links to subvolumes. Subvolumes are a completely separate b-tree, it has it's
own locking, it's own inode numbering and everything. And this isn't inode
numbering for the sake of inode numbering, our inode numbers are picked by
simply being the next largest objectid we can add to our tree. Since a
subvolume is it's own tree it's inode numbers start over at the begining.
So it's not that we can just fork off a directory and snapshot there, because
it's not a tree, it's just an item. A subvolume is its own tree, which can be
snapshotted and locked independantly from the other subvolumes. Thanks,
Josef
next prev parent reply other threads:[~2013-07-24 1:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-23 11:59 Q: Why subvolumes? Jerome Haltom
2013-07-23 14:52 ` AW: " Andreas Buschka
2013-07-23 15:06 ` Q: " Hugo Mills
2013-07-23 17:47 ` Gabriel de Perthuis
2013-07-23 19:30 ` Hugo Mills
2013-07-23 19:41 ` Gabriel de Perthuis
2013-07-23 19:43 ` Jerome Haltom
2013-07-23 21:52 ` Chris Murphy
2013-07-23 23:39 ` Jerome Haltom
2013-07-24 1:27 ` Josef Bacik [this message]
2013-07-24 2:02 ` Chris Murphy
2013-08-04 14:56 ` Alexandre Oliva
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=20130724012737.GB30875@localhost.localdomain \
--to=jbacik@fusionio.com \
--cc=g2p.code@gmail.com \
--cc=hugo@carfax.org.uk \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.com \
--cc=wasabi@cogito.cx \
/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).