Results 1 to 9 of 9

Thread: Confusion over snapper "default" snapshot

  1. #1

    Question Confusion over snapper "default" snapshot

    Love snapper/btrfs. It has saved me on numerous occasions. However, despite reading up on it I seem to have some basic confusion.

    Here's my current snapshots

    Code:
    $ sudo snapper list
    [sudo] password for root:  
    Type   | #    | Pre # | Date                          | User | Cleanup | Description           | Userdata      
    -------+------+-------+-------------------------------+------+---------+-----------------------+--------------
    single | 0    |       |                               | root |         | current               |               
    single | 1    |       | Sun 15 May 2016 07:47:50 AEST | root |         | first root filesystem |               
    single | 2032 |       | Wed 04 Apr 2018 22:14:04 AEST | root |         |                       |               
    pre    | 2050 |       | Mon 09 Apr 2018 12:11:04 AEST | root | number  | zypp(packagekitd)     | important=yes
    post   | 2051 | 2050  | Mon 09 Apr 2018 12:18:25 AEST | root | number  |                       | important=yes
    
    $ sudo btrfs subvolume get-default /
    ID 2543 gen 1723908 top level 258 path @/.snapshots/2032/snapshot
    
    $ sudo snapper status 1..2032 | wc -l   
    387527
    
    $ sudo snapper status 2032..2050 | wc -l    
    71475
    
    $ sudo snapper status 2050..2051 | wc -l
    40356
    
    My main confusion is that I would expect 0 to point to the latest snapshot 2051 (perhaps after reboot?), thus allowing me to delete 2032. Why is 0 pointing to an "earlier snapshot"?

    Also, why can I not delete 1? Essentially resetting the "base" to the current snapshot?


  2. #2
    Join Date
    Jan 2018
    Location
    Canada
    Posts
    193

    Default Re: Confusion over snapper "default" snapshot

    ‘0’ points to the snapshot you are booting from. The snapshots following ‘2032’ contain the differences based on that snapshot. I believe but stand to be corrected that 2032’ is based on ‘1”.

    The key to understanding things is that snapshots do not contain a complete picture, only a set of differences.

  3. #3

    Default Re: Confusion over snapper "default" snapshot

    Quote Originally Posted by cartland View Post
    My main confusion is that I would expect 0 to point to the latest snapshot 2051 (perhaps after reboot?), thus allowing me to delete 2032. Why is 0 pointing to an "earlier snapshot"?

    Also, why can I not delete 1? Essentially resetting the "base" to the current snapshot?

    First of all, a snapshot is, as the name suggests, a "photograph" of the filesystem at some point in time. It is not a set of differences, and does not need another snapshot to exist, it stands on its own. If you look into /.snapshot/1/snapshot you will see what your root filesystem looked like after installation, 2 years ago.

    I believe that you CAN delete 1, just do

    Code:
    snapper delete 1
    and it should go.

    Snapshot 0 is not really stored in /.snapshot because it represents the current situation. It allows you to compare any snapshot with the current situation, to see what changed since the snapshot. For instance, with
    Code:
    snapper status 1..0
    you can see all the files that are different between when you installed and now.

  4. #4
    Join Date
    Jan 2018
    Location
    Canada
    Posts
    193

    Default Re: Confusion over snapper "default" snapshot

    Quote Originally Posted by eiboaa View Post
    First of all, a snapshot is, as the name suggests, a "photograph" of the filesystem at some point in time. It is not a set of differences, and does not need another snapshot to exist, it stands on its own. If you look into /.snapshot/1/snapshot you will see what your root filesystem looked like after installation, 2 years ago.
    I don't think this is right. See Snapshots section in https://lwn.net/Articles/579009/

    The snapshot subcommand creates a snapshot of the given subvolume (the /mnt/1 root volume in this case), placing that snapshot under the requested name (/mnt/1/snapshot) in that subvolume. As a result, we now have a new subvolume called snapshot which appears to contain a full copy of everything that was in the filesystem previously. But, of course, Btrfs is a copy-on-write filesystem, so there is no need to actually copy all of that data; the snapshot simply has a reference to the current root of the filesystem. If anything is changed — in either the main volume or the snapshot — a copy of the relevant data will be made, so the other copy will remain unchanged.

    Quote Originally Posted by eiboaa View Post
    I believe that you CAN delete 1, just do

    Code:
    snapper delete 1
    and it should go.
    I tried once and you can't. A lot of searching has not turned up much info, but it looks to me like snapshot 1 is the 'mother' of everything that follows.

  5. #5

    Default Re: Confusion over snapper "default" snapshot

    Quote Originally Posted by doscott View Post
    I don't think this is right. See Snapshots section in https://lwn.net/Articles/579009/

    Btrfs is a copy-on-write filesystem, so there is no need to actually copy all of that data; the snapshot simply has a reference to the current root of the filesystem. If anything is changed — in either the main volume or the snapshot — a copy of the relevant data will be made, so the other copy will remain unchanged.
    This is saying that when you take a snapshot you make a full copy of the filesystem. However, since btrfs is copy-on-write it actually creates something that I believe we can think of as a hard-link to the file, instead of making an actual copy. If at any point in time the linked file is modified then the copy is actually made.This is different, though, from differential backups, where only the files that have changed since the previous backup are stored. The snapshot is always a full copy (but it's lightweight, because of the CoW mechanism).

    Also, the same guide you quote reads:

    A snapshot in Btrfs is a special type of subvolume — one which contains a copy of the current state of some other subvolume
    it doesn't say anything about the copy being differential...


    I tried once and you can't.
    This I can't explain... where you root?

    For instance I don't have any "mother" snapshot, I have the current situation:

    Code:
    Type   | #  | Pre # | Date                         | User | Cleanup | Description           | Userdata     
    -------+----+-------+------------------------------+------+---------+-----------------------+--------------
    single | 0  |       |                              | root |         | current               |              
    single | 2  |       | Mon 09 Apr 2018 12:52:13 BST | root | number  | after installation    | important=yes
    pre    | 20 |       | Mon 09 Apr 2018 19:14:45 BST | root | number  | zypp(ruby.ruby2.5)    | important=yes
    post   | 21 | 20    | Mon 09 Apr 2018 19:19:46 BST | root | number  |                       | important=yes
    single | 25 |       | Mon 09 Apr 2018 19:42:59 BST | root | number  | rollback backup of #1 | important=yes
    single | 26 |       | Mon 09 Apr 2018 19:43:00 BST | root |         |                       |              
    pre    | 37 |       | Tue 10 Apr 2018 11:39:20 BST | root | number  | yast sw_single        |              
    pre    | 38 |       | Tue 10 Apr 2018 11:39:54 BST | root | number  | zypp(ruby.ruby2.5)    | important=no 
    post   | 39 | 38    | Tue 10 Apr 2018 11:39:59 BST | root | number  |                       | important=no 
    post   | 40 | 37    | Tue 10 Apr 2018 11:40:02 BST | root | number  |                       |              
    pre    | 41 |       | Tue 10 Apr 2018 11:40:19 BST | root | number  | yast sw_single        |              
    pre    | 42 |       | Tue 10 Apr 2018 11:40:43 BST | root | number  | zypp(ruby.ruby2.5)    | important=no 
    post   | 43 | 42    | Tue 10 Apr 2018 11:41:37 BST | root | number  |                       | important=no 
    post   | 44 | 41    | Tue 10 Apr 2018 11:44:28 BST | root | number  |                       |              
    pre    | 45 |       | Tue 10 Apr 2018 14:00:21 BST | root | number  | zypp(packagekitd)     | important=yes
    post   | 46 | 45    | Tue 10 Apr 2018 14:02:13 BST | root | number  |                       | important=yes
    where even snapshot 2 will be deleted by the "number" algorithm when its time comes (it keeps 10 "important" ones and right now I only have 6). Also, as you can see #1 is gone.

    Furthermore, the openSUSE tutorial says: https://en.opensuse.org/openSUSE:Sna...ting_Snapshots

    Delete all snapshots (assuming you have no more than 100000 of them) you'd do:

    Code:
    snapper delete 1-100000 (snapper delete number1-number2)
    so it doesn't look like #1 should be special.

  6. #6
    Join Date
    Jan 2018
    Location
    Canada
    Posts
    193

    Default Re: Confusion over snapper "default" snapshot

    I think we are arguing over semantics. A "full" copy is either "full" or not, but I don't thing it can be "full" and "lightweight".

    As far as deleting 1, yes I was root and I couldn't delete it. And just to prove it, I tried again, and guess what? It got deleted! Live and learn.

  7. #7
    Join Date
    Jan 2018
    Location
    Canada
    Posts
    193

    Default Re: Confusion over snapper "default" snapshot

    I think I have found why I could not delete snapshot 1 previously.

    Installations after Jan 2018 are set up differently https://en.opensuse.org/SDB:BTRFS

    I have an older installation with docker installed, and whenever I did a rollback the docker images got messed up and took a lot of manual editing to get working again. Recently I created a new partition /var/lib/docker, formatted it ext4 and mounted it and reinstalled docker. I manually removed all the btrfs docker snapshots I could find. Now it works like a charm, and appears to let me delete snapshot 1.

  8. #8

    Default Re: Confusion over snapper "default" snapshot

    Quote Originally Posted by doscott View Post
    I think we are arguing over semantics. A "full" copy is either "full" or not, but I don't thing it can be "full" and "lightweight".
    ok, sorry, I'll clarify.

    This is what I mean: a differential backup, with respect to a previous backup, only copies the files that have changed since the previous backup. A full backup copies every file regardless of any previous backup. Snapshots are full backups. They don't depend on any previous snapshot, and you can delete any snapshot you want, you'll still be able to use the ones that are left. In a differential backup you need the whole sequence of backups to reconstruct the filesystems, while with snapshots you only need one.

    Now for the lightweight part. This is entirely depending on Copy-on-Write. If the filesystem wasn't CoW each snapshot would duplicate each file. With CoW, however, the file is actually copied only when necessary, that is when the original file is modified. In practice, therefore, the snapshots only hold the files that have changed since that snapshot was taken and something analogous to links to the files that didn't change.

    Now I hope this is right


    Quote Originally Posted by doscott View Post
    As far as deleting 1, yes I was root and I couldn't delete it. And just to prove it, I tried again, and guess what? It got deleted! Live and learn.
    lol

  9. #9

    Default Re: Confusion over snapper "default" snapshot

    Quote Originally Posted by doscott View Post
    As far as deleting 1, yes I was root and I couldn't delete it. And just to prove it, I tried again, and guess what? It got deleted! Live and learn.
    Yup. Me too! I recovered quite a bit of disk space.

    Code:
    Type   | #    | Pre # | Date                          | User | Cleanup | Description       | Userdata      
    -------+------+-------+-------------------------------+------+---------+-------------------+--------------
    single | 0    |       |                               | root |         | current           |               
    single | 2032 |       | Wed 04 Apr 2018 22:14:04 AEST | root |         |                   |               
    pre    | 2050 |       | Mon 09 Apr 2018 12:11:04 AEST | root | number  | zypp(packagekitd) | important=yes
    post   | 2051 | 2050  | Mon 09 Apr 2018 12:18:25 AEST | root | number  |                   | important=yes
    pre    | 2052 |       | Wed 11 Apr 2018 21:05:20 AEST | root | number  | zypp(packagekitd) | important=yes
    post   | 2053 | 2052  | Wed 11 Apr 2018 21:21:35 AEST | root | number  |                   | important=yes
    
    Thanks for the discussion. It clarified things.

    Looking into the above. The snapshots with higher numbers are later than earlier ones. Once exception the current "snapshot" 2032 which represents the current system state. Hence some of my confusion. So there are minimal differences between the snapshot 2053 and the current bootable system represented by 2032.

    So all system changes now and forever are applied to 2032. Except if I do a rollback to a higher number number snapshot, in which case the number of the default current snapshot will increase to that new number. I was wondering how the current snapshot number increased - my other confusion.

    So, unless I got any of that wrong, I'm clear now.

    Thanks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •