public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Nikolay Borisov <nborisov@suse.com>
To: Andrei Borzenkov <arvidjaar@gmail.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: how do I know a subvolume is a snapshot?
Date: Wed, 17 Jul 2019 14:19:48 +0300	[thread overview]
Message-ID: <18c3652a-ee3d-a56f-7ebf-1be92d112426@suse.com> (raw)
In-Reply-To: <CAA91j0U1QBruk+JPE4+FZwuKNOz+YeiQOaeM58Viu6iSCYc99g@mail.gmail.com>



On 17.07.19 г. 13:29 ч., Andrei Borzenkov wrote:
> On Wed, Jul 17, 2019 at 1:14 PM Nikolay Borisov <nborisov@suse.com> wrote:
>>
>>
>>
>> On 17.07.19 г. 12:11 ч., Ulli Horlacher wrote:
>>> On Wed 2019-07-17 (11:24), Nikolay Borisov wrote:
>>>>
>>>>
>>>> On 17.07.19 3. 2:24 G., Ulli Horlacher wrote:
>>>>
>>>>> I thought, I can recognize a snapshot when it has a Parent UUID, but this
>>>>> is not true for snapshots of toplevel subvolumes:
>>>>
>>>> As you have asked this before - in my testing this is not true.
>>>
>>> It is true on all my SUSE and Ubuntu systems, for all versions.
>>
>> That's strange, as I've shown in the previous thread, using the latest
>> master doesn't exhibit this behavior.
> 
> I doubt you are not aware that distributions rarely use latest master.
> 
> Actually I have here openSUSE Tumbleweed; root top level subvolume
> does not have UUID but if I create new filesystem *now* it does. btrfs
> tools have been updated since initial installation.

I have an ubuntu 18.04 installation lying around and I see : 

sudo btrfs subvolume show btrfs-mount/
/
	Name: 			<FS_TREE>
	UUID: 			-
	Parent UUID: 		-
	Received UUID: 		-
	Creation time: 		-
	Subvolume ID: 		5
	Generation: 		4
	Gen at creation: 	0
	Parent ID: 		0
	Top level ID: 		0
	Flags: 			-
	Snapshot(s):

This is really odd... So this indeed seems to be a userspace problem. 
However, creating a subvolume and then a snapshot I see sane output - parent UUID being there and UUID being there for a kernel-created subvol. : 

nborisov@fisk:~/projects/kernel/source$ sudo btrfs subvolume show btrfs-mount/subvol1-snap1/
subvol1-snap1
	Name: 			subvol1-snap1
	UUID: 			3aebb55e-57bc-9c46-9a34-4ac0220d602e
	Parent UUID: 		fe7e68c6-b9c8-ce4d-8467-7229bd39b0eb
	Received UUID: 		-
	Creation time: 		2019-07-17 13:55:31 +0300
	Subvolume ID: 		258
	Generation: 		9
	Gen at creation: 	9
	Parent ID: 		5
	Top level ID: 		5
	Flags: 			-
	Snapshot(s):

nborisov@fisk:~/projects/kernel/source$ sudo btrfs subvolume show btrfs-mount/subvolume1/
subvolume1
	Name: 			subvolume1
	UUID: 			fe7e68c6-b9c8-ce4d-8467-7229bd39b0eb
	Parent UUID: 		-
	Received UUID: 		-
	Creation time: 		2019-07-17 13:55:14 +0300
	Subvolume ID: 		257
	Generation: 		9
	Gen at creation: 	8
	Parent ID: 		5
	Top level ID: 		5
	Flags: 			-
	Snapshot(s):
				subvol1-snap1


> 
> Better question would be - is it possible to fix it for existing
> filesystems that had been created using old tools?
> 

  reply	other threads:[~2019-07-17 11:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-16 23:24 how do I know a subvolume is a snapshot? Ulli Horlacher
2019-07-17  7:45 ` Bernhard Kühnel
2019-07-17  8:05   ` Ulli Horlacher
2019-07-17 10:33   ` Remi Gauvin
2019-07-17  8:23 ` Hans van Kranenburg
2019-07-17  8:57   ` misono.tomohiro
2019-07-17  9:06     ` Ulli Horlacher
2019-07-17  9:24       ` misono.tomohiro
2019-07-17  8:24 ` Nikolay Borisov
2019-07-17  9:11   ` Ulli Horlacher
2019-07-17 10:11     ` Nikolay Borisov
2019-07-17 10:29       ` Andrei Borzenkov
2019-07-17 11:19         ` Nikolay Borisov [this message]
2019-07-17 17:39           ` Andrei Borzenkov
2019-07-17 18:16             ` Nikolay Borisov

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=18c3652a-ee3d-a56f-7ebf-1be92d112426@suse.com \
    --to=nborisov@suse.com \
    --cc=arvidjaar@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox