linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc MERLIN <marc@merlins.org>
To: Chris Murphy <lists@colorremedies.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Can a snapshot become a parent subvolume when its parent is deleted?
Date: Sun, 18 May 2014 18:11:55 -0700	[thread overview]
Message-ID: <20140519011155.GJ10566@merlins.org> (raw)
In-Reply-To: <FA8D4920-8A23-4C8D-848F-EC52BF43311C@colorremedies.com>

On Wed, May 14, 2014 at 12:09:38PM -0600, Chris Murphy wrote:
> 
> On May 14, 2014, at 7:50 AM, Marc MERLIN <marc@merlins.org> wrote:
> 
> > So, I had btrfs_pool1 that was trashed/lost as discussed here recently.
> > 
> > I did btrfs send btrfs_pool2/root_ro.date | btrfs receive /mnt/btrfs_pool1
> > 
> > Then btrfs subvolume snapshot root_ro.date root
> > 
> > Now, after I delete root_ro.date on btrfs_pool1, shouldn't root become a
> > parent subvolume?
> 
> There's no explicit hierarchy like this. There's no state "parent" or "child". 
> 
> If a subvolume is created by snapshotting another subvolume, the new
> subvolume refers to the uuid of its source as the parent uuid. And
> the original subvolume, at least in the UI, contains a list of its
> snapshots but I don't know that this metadata is literally associated
> with the subvolume rather than inferred from its snapshots, all of
> which contain the "parent" subvolume's uuid as a parent_uuid.

Right. So basically the parent UUID can go orphanned, which I found a
bit surprising.

> > Right now, I have:
> > legolas:/mnt/btrfs_pool1# btrfs subvolume list -q . 
> > ID 390 gen 5954 top level 5 parent_uuid faea7df8-d51a-6b4b-994b-887d55267cce path root
> > legolas:/mnt/btrfs_pool1# btrfs subvolume list  -u .  |grep faea7df8-d51a-6b4b-994b-887d55267cce
> > legolas:/mnt/btrfs_pool1#
> > 
> > Is it possible not to have a parent?
> > 
> > If so, shouldn't you become a parent at that time?
> 
> No. The listed subvolume parent_uuid is the subvolume uuid for
> now deleted subvolume root_ro.date. Even though it's deleted, the
> subvolume created from it still retains the parent_uuid reference.

Yep. If you think about daemonized processed that get inherited by init,
shouldn't parent-less snapshots change their parent uuid to '-'
 
> If you snapshot root, you could say it "becomes a parent" but it's
> only a metaphor it's not something that literally happens on disk. All
> I'm aware of that happens is the new subvolume gets its own uuid and
> its parent_uuid is set to match the subvolume uuid it was created
> from.

You are correct. The blocks don't care who is the parent and child
subvolume, they're just references.
But for management purposes by us humans :) it's useful to know what's
going on.

Would a developer agree to making parent less subvolumes have their
parent become '-'?

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/                         | PGP 1024R/763BE901

      reply	other threads:[~2014-05-19  1:12 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-14 13:50 Can a snapshot become a parent subvolume when its parent is deleted? Marc MERLIN
2014-05-14 18:09 ` Chris Murphy
2014-05-19  1:11   ` Marc MERLIN [this message]

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=20140519011155.GJ10566@merlins.org \
    --to=marc@merlins.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.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).