From: Chris Mason <chris.mason@fusionio.com>
To: Alexander Block <ablock84@googlemail.com>
Cc: "kreijack@inwind.it" <kreijack@inwind.it>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: [RFC] Btrfs "sendshots" and hidden snapshots
Date: Fri, 6 Jul 2012 07:55:24 -0400 [thread overview]
Message-ID: <20120706115524.GH7159@shiny> (raw)
In-Reply-To: <CAB9VWqBcZNc7unKA9sFC9nUrBgCB=G3tsDy89QXiQBmdvzbkwA@mail.gmail.com>
On Fri, Jul 06, 2012 at 02:51:43AM -0600, Alexander Block wrote:
> On Fri, Jul 6, 2012 at 12:34 AM, Goffredo Baroncelli <kreijack@libero.it> wrote:
> > On 07/05/2012 06:51 PM, Alexander Block wrote:
> >> Hello all,
> >>
> >> in IRC we had a discussion on how we could solve sending live
> >> subvolumes and how to send subvolumes without the need to
> >> administrate/keep old snapshots for incremental sends. One of the
> >> ideas was to introduce "sendshots", which are basically snapshots
> >> where no refs are counted for file data. This means, that when file
> >> data is changed in the sendshot origin, we do not consume extra space
> >> for two copies of the data. We would only have the metadata
> >> duplicated.
> >>
> >> For the initial btrfs send we could do this:
> >> 1. Create a hidden read-only snapshot of the subvolume to send. Hidden
> >> means that it's not referenced by any subvolume. It is however still a
> >> normal snapshot (not a sendshot!). Hidden snapshots are not possible
> >> atm so we would have to implement that. This step allows us to send
> >> read-write subvolumes, because we have a freezed version of it.
> >
> > Why we should want/need an hidden snapshot ? We could put this kind of
> > hidden snapshot under a directory dot-prefixed (like /.hidden-subvolumes)
> That would have the problem that the user may modify the subvolume
> in-between (by removing the ro flag). Or he could simple cd into it
> and we would later fail to delete it.
I prefer to make this more explicit. We could add a hard-readonly flag
that cannot be cleared. Having the snapshot show in the FS lets the
admin know what things are really using space.
-chris
next prev parent reply other threads:[~2012-07-06 11:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-05 16:51 [RFC] Btrfs "sendshots" and hidden snapshots Alexander Block
2012-07-05 22:34 ` Goffredo Baroncelli
2012-07-06 8:51 ` Alexander Block
2012-07-06 11:55 ` Chris Mason [this message]
2012-07-06 12:03 ` Goffredo Baroncelli
2012-07-06 12:45 ` Alexander Block
2012-07-09 15:51 ` Goffredo Baroncelli
2012-07-06 12:00 ` 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=20120706115524.GH7159@shiny \
--to=chris.mason@fusionio.com \
--cc=ablock84@googlemail.com \
--cc=kreijack@inwind.it \
--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.