how do I know a subvolume is a snapshot?

How do I know that /mnt/tmp/ss is a snapshot?
I cannot see a snapshot identifier.

       A snapshot is a subvolume like any other, with given initial

       read-write. File modifications in a snapshot do not affect the

Am 17.07.2019 um 01:24 schrieb Ulli Horlacher:

Quoted 2 lines

How do I know that /mnt/tmp/ss is a snapshot?
I cannot see a snapshot identifier.

From the btrfs-subvolume man page:

Quoted 2 lines

       A snapshot is a subvolume like any other, with given initial content. By default, snapshots are created read-write. File modifications in a snapshot do not affect the files in the original subvolume.

I believe the usual practice is to create snapshots with the -r flag and follow some naming convention (e.g. place them in a common .snapshots folder named by date), but you're free to switch between read-only and read-write mode for a snapshot at any time using the btrfs property command.

I believe the usual practice is to create snapshots with the -r flag and follow some naming convention (e.g. place them in a common .snapshots folder named by date), but you're free to switch between read-only and read-write mode for a snapshot at any time using the btrfs property command.

That allows for some intereresting feats: e.g. there's no guarantee that a (now) read-only snapshot actually reflects the source's state at creation time (if someone modified it and re-applied the ro flag). On the other hand, reverting to a snapshotted state may be as easy as making the snapshot rw and changing the mount options to use it's subvolid - no need to copy any files back and forth.

I thought, I can recognize a snapshot when it has a Parent UUID, but this is not true for snapshots of toplevel subvolumes:

root@trulla:/# btrfs version
btrfs-progs v4.5.3+20160729

root@trulla:/# btrfs subvolume show /mnt/tmp
/mnt/tmp is toplevel subvolume

root@trulla:/# btrfs subvolume snapshot /mnt/tmp /mnt/tmp/ss
Create a snapshot of '/mnt/tmp' in '/mnt/tmp/ss'

root@trulla:/# btrfs subvolume create /mnt/tmp/xx
Create subvolume '/mnt/tmp/xx'

root@trulla:/# btrfs subvolume show /mnt/tmp/ss
/mnt/tmp/ss
        Name:                   ss
        UUID:                   7732bdde-0485-204e-b41b-833376e791da
        Parent UUID:            -
        Received UUID:          -
        Creation time:          2019-07-17 01:02:48 +0200
        Subvolume ID:           270
        Generation:             60
        Gen at creation:        60
        Parent ID:              5
        Top level ID:           5
        Flags:                  -
        Snapshot(s):

root@trulla:/# btrfs subvolume show /mnt/tmp/xx
/mnt/tmp/xx
        Name:                   xx
        UUID:                   342b2065-1679-8245-bd76-8da598cc33d8
        Parent UUID:            -
        Received UUID:          -
        Creation time:          2019-07-17 01:03:02 +0200
        Subvolume ID:           271
        Generation:             61
        Gen at creation:        61
        Parent ID:              5
        Top level ID:           5
        Flags:                  -
        Snapshot(s):

How do I know that /mnt/tmp/ss is a snapshot?
I cannot see a snapshot identifier.

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Hans van Kranenburg
Sent: Wednesday, July 17, 2019 5:24 PM
To: [email protected]; Ulli Horlacher <[email protected]>
Subject: Re: how do I know a subvolume is a snapshot?

Hi,

Quoted 44 lines · Ulli Horlacher

I thought, I can recognize a snapshot when it has a Parent UUID, but this is not true for snapshots of toplevel subvolumes:

root@trulla:/# btrfs version
btrfs-progs v4.5.3+20160729

root@trulla:/# btrfs subvolume show /mnt/tmp /mnt/tmp is toplevel
subvolume

root@trulla:/# btrfs subvolume snapshot /mnt/tmp /mnt/tmp/ss Create a
snapshot of '/mnt/tmp' in '/mnt/tmp/ss'

root@trulla:/# btrfs subvolume create /mnt/tmp/xx Create subvolume
'/mnt/tmp/xx'

root@trulla:/# btrfs subvolume show /mnt/tmp/ss /mnt/tmp/ss
        Name:                   ss
        UUID:                   7732bdde-0485-204e-b41b-833376e791da
        Parent UUID:            -
        Received UUID:          -
        Creation time:          2019-07-17 01:02:48 +0200
        Subvolume ID:           270
        Generation:             60
        Gen at creation:        60
        Parent ID:              5
        Top level ID:           5
        Flags:                  -
        Snapshot(s):

root@trulla:/# btrfs subvolume show /mnt/tmp/xx /mnt/tmp/xx
        Name:                   xx
        UUID:                   342b2065-1679-8245-bd76-8da598cc33d8
        Parent UUID:            -
        Received UUID:          -
        Creation time:          2019-07-17 01:03:02 +0200
        Subvolume ID:           271
        Generation:             61
        Gen at creation:        61
        Parent ID:              5
        Top level ID:           5
        Flags:                  -
        Snapshot(s):

Quoted 3 lines

How do I know that /mnt/tmp/ss is a snapshot?
I cannot see a snapshot identifier.

The technical answer is:

* The uuid of the top-level subvol (id 5) is
00000000-0000-0000-0000-000000000000
* The parent uuid of your snapshot/clone is also 0000... as a result.
* For interpretation of parent uuid field, there is no distinction between "has no parent uuid" (the field is empty, which technically means all bits are 0) and the actual value 0000...
* So... the tooling displays it as "-". ¯\_(ツ)_/¯

The practical answer is:

* Don't put anything in the top level subvol that would make you want to snapshot it.

Note: In btrfs design, there is no technical difference between a snapshot and a writable clone (as opposed to e.g. netapp snapshots and clones). This makes the design less complicated, but it results in a collection of known usability issues, like that if you expect them to be different, they still aren't.

Hans

FYI, this problem should be fixed in mkfs.btrfs >= v4.16 since the top-level subvolume also gets non-empty UUID at mkfs time.

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Ulli Horlacher
Sent: Wednesday, July 17, 2019 6:07 PM
To: [email protected]
Subject: Re: how do I know a subvolume is a snapshot?

Quoted 2 lines · On Wed 2019-07-17 (08:57), [email protected] wrote:

FYI, this problem should be fixed in mkfs.btrfs >= v4.16 since the top-level subvolume also gets non-empty UUID at mkfs time.

root@fex:~# lsb_release -d
Description:    Ubuntu 18.04.2 LTS

root@fex:~# btrfs version
btrfs-progs v4.15.1

*sigh*

root@fex:~# uname -a
Linux fex 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24 10:55:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Can I use/install a newer mkfs.btrfs or do I also have to install a newer kernel version?

I thought, I can recognize a snapshot when it has a Parent UUID, but this is not true for snapshots of toplevel subvolumes:

Quoted 2 lines · Ulli Horlacher

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.

Alternatively you have to parse the root tree - the ROOT_ITEM's offset member should be 0 for well-known trees/ordinary subvolume or the transaction id when the snapshot was created.

Quoted 8 lines · Nikolay Borisov

Quoted 2 lines · Ulli Horlacher

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.

Quoted 5 lines

Alternatively you have to parse the root tree - the ROOT_ITEM's offset member should be 0 for well-known trees/ordinary subvolume or the transaction id when the snapshot was created.

Where can I find this ROOT_ITEM offset member? Which command?

Quoted 8 lines · Ulli Horlacher

Quoted 7 lines · Nikolay Borisov

Quoted 2 lines · Ulli Horlacher

I thought, I can recognize a snapshot when it has a Parent UUID, but this is not true for snapshots of toplevel subvolumes:

Quoted 3 lines

Quoted 1 line

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.

Quoted 16 lines · Nikolay Borisov

Quoted 11 lines · Ulli Horlacher

Quoted 8 lines · Nikolay Borisov

Quoted 2 lines · Ulli Horlacher

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.

Quoted 2 lines

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.

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

This is really odd... So this indeed seems to be a userspace problem.

17.07.2019 14:19, Nikolay Borisov пишет:

Quoted 2 lines

This is really odd... So this indeed seems to be a userspace problem.

Of course it is user space problem.

commit 0a0a03554aaf56a6e7245e74fa7d8b3c53f1c20f

Author: Misono Tomohiro <[email protected]>
Date:   Fri Mar 23 17:16:49 2018 +0900

btrfs-progs: mkfs: add uuid and otime to ROOT_ITEM of, FS_TREE

Currently, the top-level subvolume lacks the UUID. As a result, both non-snapshot subvolume and snapshot of top-level subvolume do not have Parent UUID and cannot be distinguisued. Therefore "fi show" of top-level lists all the subvolumes which lacks the UUID in "Snapshot(s)" filed. Also, it lacks the otime information.

Fix this by adding the UUID and otime at the mkfs time. As a consequence, snapshots of top-level subvolume now have a Parent UUID and UUID tree will create an entry for top-level subvolume at mount time. This should not cause the problem for current kernel, but user program which relies on the empty Parent UUID may be affected by this change.

What about the question - is there tool to fix existing filesystem by adding this information?