* Btrfs uuid snapshots: orphaned parent_uuid after deleting intermediate subvol
@ 2016-07-15 23:12 Eric Wheeler
2016-07-16 10:18 ` Kai Krakow
0 siblings, 1 reply; 3+ messages in thread
From: Eric Wheeler @ 2016-07-15 23:12 UTC (permalink / raw)
To: linux-btrfs
Hello all,
If I create three subvolumes like so:
# btrfs subvolume create a
# btrfs subvolume snapshot a b
# btrfs subvolume snapshot b c
I get a parent-child relationship which can be determined like so:
# btrfs subvolume list -uq /home/ |grep [abc]$
parent_uuid - uuid 0e5f473a-d9e5-144a-8f49-1899af7320ad path a
parent_uuid 0e5f473a-d9e5-144a-8f49-1899af7320ad uuid cb4768eb-98e3-5e4c-935d-14f1b97b0de2 path b
parent_uuid cb4768eb-98e3-5e4c-935d-14f1b97b0de2 uuid 5ee8de35-2bab-d642-b5c2-f619e46f65c2 path c
Now if I delete 'b', the parent_uuid of 'c' doesn't change to point at 'a':
# btrfs subvolume delete b
# btrfs subvolume list -uq /home/ |grep [abc]$
parent_uuid - uuid 0e5f473a-d9e5-144a-8f49-1899af7320ad path a
parent_uuid cb4768eb-98e3-5e4c-935d-14f1b97b0de2 uuid 5ee8de35-2bab-d642-b5c2-f619e46f65c2 path c
Notice that 'c' still points at b's UUID, but 'b' is missing and the
parent_uuid for 'c' wasn't set to '-' as if it were a root node (like 'a').
Is this an inconsistency? Child parent_uuid's it be updated on delete?
It would be nice to know that 'c' is actually a descendent of 'a', even
after having deleted 'b'. Is a way to look that up somehow?
This is running 4.1.15, so its a bit behind. If this is fixed in a later
version then please let me know that too. Thanks!
--
Eric Wheeler
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Btrfs uuid snapshots: orphaned parent_uuid after deleting intermediate subvol
2016-07-15 23:12 Btrfs uuid snapshots: orphaned parent_uuid after deleting intermediate subvol Eric Wheeler
@ 2016-07-16 10:18 ` Kai Krakow
2016-07-16 10:25 ` Hugo Mills
0 siblings, 1 reply; 3+ messages in thread
From: Kai Krakow @ 2016-07-16 10:18 UTC (permalink / raw)
To: linux-btrfs
Am Fri, 15 Jul 2016 16:12:51 -0700 (PDT)
schrieb Eric Wheeler <btrfs@lists.ewheeler.net>:
> Hello all,
>
> If I create three subvolumes like so:
>
> # btrfs subvolume create a
> # btrfs subvolume snapshot a b
> # btrfs subvolume snapshot b c
>
> I get a parent-child relationship which can be determined like so:
>
> # btrfs subvolume list -uq /home/ |grep [abc]$
> parent_uuid - uuid 0e5f473a-d9e5-144a-8f49-1899af7320ad path a
> parent_uuid 0e5f473a-d9e5-144a-8f49-1899af7320ad uuid
> cb4768eb-98e3-5e4c-935d-14f1b97b0de2 path b parent_uuid
> cb4768eb-98e3-5e4c-935d-14f1b97b0de2 uuid
> 5ee8de35-2bab-d642-b5c2-f619e46f65c2 path c
>
> Now if I delete 'b', the parent_uuid of 'c' doesn't change to point
> at 'a':
>
> # btrfs subvolume delete b
> # btrfs subvolume list -uq /home/ |grep [abc]$
> parent_uuid - uuid 0e5f473a-d9e5-144a-8f49-1899af7320ad path a
> parent_uuid cb4768eb-98e3-5e4c-935d-14f1b97b0de2 uuid
> 5ee8de35-2bab-d642-b5c2-f619e46f65c2 path c
It cannot do that because b may have diverged from a.
> Notice that 'c' still points at b's UUID, but 'b' is missing and the
> parent_uuid for 'c' wasn't set to '-' as if it were a root node (like
> 'a').
>
> Is this an inconsistency? Child parent_uuid's it be updated on
> delete?
I think this is by design. This "missing" UUID is now no longer a file
system tree, it's just referencing blocks different between a and c at
the time of deleting b.
> It would be nice to know that 'c' is actually a descendent of 'a',
> even after having deleted 'b'. Is a way to look that up somehow?
Actually it would also be interesting what happens with blocks in
deleted b after the blocks in c are unshared? Are they garbage
collected or do we have some orphan subvolume lying around which you
cannot get rid of?
--
Regards,
Kai
Replies to list-only preferred.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Btrfs uuid snapshots: orphaned parent_uuid after deleting intermediate subvol
2016-07-16 10:18 ` Kai Krakow
@ 2016-07-16 10:25 ` Hugo Mills
0 siblings, 0 replies; 3+ messages in thread
From: Hugo Mills @ 2016-07-16 10:25 UTC (permalink / raw)
To: Kai Krakow; +Cc: linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 2813 bytes --]
On Sat, Jul 16, 2016 at 12:18:18PM +0200, Kai Krakow wrote:
> Am Fri, 15 Jul 2016 16:12:51 -0700 (PDT)
> schrieb Eric Wheeler <btrfs@lists.ewheeler.net>:
>
> > Hello all,
> >
> > If I create three subvolumes like so:
> >
> > # btrfs subvolume create a
> > # btrfs subvolume snapshot a b
> > # btrfs subvolume snapshot b c
> >
> > I get a parent-child relationship which can be determined like so:
> >
> > # btrfs subvolume list -uq /home/ |grep [abc]$
> > parent_uuid - uuid 0e5f473a-d9e5-144a-8f49-1899af7320ad path a
> > parent_uuid 0e5f473a-d9e5-144a-8f49-1899af7320ad uuid
> > cb4768eb-98e3-5e4c-935d-14f1b97b0de2 path b parent_uuid
> > cb4768eb-98e3-5e4c-935d-14f1b97b0de2 uuid
> > 5ee8de35-2bab-d642-b5c2-f619e46f65c2 path c
> >
> > Now if I delete 'b', the parent_uuid of 'c' doesn't change to point
> > at 'a':
Correct -- the parent is the subvol that the snapshot was made
from. After you make a snapshot, the snapshot and its original
subvolume are entirely equal partners, so there's no parent-child
relationship between them for purposes of data storage or anything
like that. The parent_uuid field is only used by send -p to ensure
correctness, and for nothing else.
> > # btrfs subvolume delete b
> > # btrfs subvolume list -uq /home/ |grep [abc]$
> > parent_uuid - uuid 0e5f473a-d9e5-144a-8f49-1899af7320ad path a
> > parent_uuid cb4768eb-98e3-5e4c-935d-14f1b97b0de2 uuid
> > 5ee8de35-2bab-d642-b5c2-f619e46f65c2 path c
>
> It cannot do that because b may have diverged from a.
>
> > Notice that 'c' still points at b's UUID, but 'b' is missing and the
> > parent_uuid for 'c' wasn't set to '-' as if it were a root node (like
> > 'a').
> >
> > Is this an inconsistency? Child parent_uuid's it be updated on
> > delete?
It's not inconsistent. I think it just doesn't mean what you
thought it did. :)
> I think this is by design. This "missing" UUID is now no longer a file
> system tree, it's just referencing blocks different between a and c at
> the time of deleting b.
> > It would be nice to know that 'c' is actually a descendent of 'a',
> > even after having deleted 'b'. Is a way to look that up somehow?
>
> Actually it would also be interesting what happens with blocks in
> deleted b after the blocks in c are unshared? Are they garbage
> collected or do we have some orphan subvolume lying around which you
> cannot get rid of?
They're GCed. Extents are simply reference counted -- it doesn't
matter how those references got there, or in what order. When the
reference count drops to zero, the extent is cleaned up.
Hugo.
--
Hugo Mills | Great oxymorons of the world, no. 9:
hugo@... carfax.org.uk | Standard Deviation
http://carfax.org.uk/ |
PGP: E2AB1DE4 |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-07-16 10:25 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-07-15 23:12 Btrfs uuid snapshots: orphaned parent_uuid after deleting intermediate subvol Eric Wheeler
2016-07-16 10:18 ` Kai Krakow
2016-07-16 10:25 ` Hugo Mills
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.