Re: IO Error (.snapshots is not a btrfs subvolume)

[Nick Gilmour <nickeforos@gmail.com>]

On Thu, Feb 8, 2018 at 5:32 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
> 08.02.2018 06:03, Chris Murphy пишет:
>> On Wed, Feb 7, 2018 at 6:26 PM, Nick Gilmour <nickeforos@gmail.com> wrote:
>>> Hi all,
>>>
>>> I have successfully restored a snapshot of root but now when I try to
>
> How exactly was it done?
>
>>> make a new snapshot I get this error:
>>> IO Error (.snapshots is not a btrfs subvolume).
>>> My snapshots were within @ which I renamed to @_old.
>>> What can I do now? How can I move the snapshots from @_old/ into @ and
>>> be able to make snapshots again?
>>>
>>> This is an excerpt of my subvolumes list:
>>>
>>> # btrfs subvolume list /
>>> ID 257 gen 175397 top level 5 path @_old
>>> ID 258 gen 175392 top level 5 path @pkg
>>> ID 260 gen 175447 top level 5 path @tmp
>>> ID 262 gen 19 top level 257 path @_old/var/lib/machines
>>> ID 268 gen 175441 top level 5 path @test
>>> ID 291 gen 175394 top level 257 path @_old/.snapshots
>>> ID 292 gen 1705 top level 291 path @_old/.snapshots/1/snapshot
>>> ...
>>>
>>> ID 3538 gen 175398 top level 291 path @_old/.snapshots/1594/snapshot
>>> ID 3540 gen 175447 top level 5 path @
>>>
>>
>>
>> This is a snapper behavior. It creates .snapshots as a subvolume and
>> then puts snapshots into that subvolume. If you snapshot a subvolume
>> that contains another subvolume, the nested subvolume is not snapshot,
>> instead a plain directory placeholder is created instead. So your
>> restored snapshot contains a .snapshot directory rather than a
>> .snapshot subvolume. Possibly if you delete the directory and create a
>> new subvolume .snapshot, the problem will be fixed.
>>
>
> No, you should create subvolume @/.snapshots and mount it as /.snapshots
> (and have it in /etc/fstab). Snapshots should always be available in
> running system under fixed path and this only possible when it is
> mounted, otherwise after rollback /.snapshots will be lost just like it
> happened now.
>
> Exact subvolume name probably not matters that much, but better stick
> with what installer does by default. It may matter for grub2 snapshots
> handling.
>
> Also openSUSE expects that actual root is subvolume under /.snapshots
> which is valid snapper snapshot (i.e. it has valid metadata). Again, not
> having this may confuse snapper.
>
> It may be possible to move @_old/.snapshots into @/.snapshots, although
> this breaks parent-child relationships those old snapshots cannot be
> cleaned up without removing old root completely.
>
>> I can't tell you how this will confuse snapper though, or how to
>> unconfuse it. It pretty much expects to be in control of all
>> snapshots, creation, deletion, and rollbacks. So if you do it manually
>> for whatever reason, I think it can confuse snapper.
>>
>>
>
> There was blog post recently outlining how to restore openSUSE root. You
> may want to search opensuse or opensuse-factory mailing list. Ah found:
>
> https://rootco.de/2018-01-19-opensuse-btrfs-subvolumes/


Thanks both for the quick responses!

> How exactly was it done?
1. # mount /dev/sde6 /mnt
2. # cd /mnt
3. # mv @ @_old
4. # btrfs subvol snapshot /mnt/@_old/.snapshots/1594/snapshot /mnt/@

> No, you should create subvolume @/.snapshots and mount it as /.snapshots
> (and have it in /etc/fstab). Snapshots should always be available in
> running system under fixed path and this only possible when it is
> mounted, otherwise after rollback /.snapshots will be lost just like it
> happened now.

When I run this command I get an error:
# btrfs subvolume create @/.snapshots
ERROR: cannot access '@': No such file or directory

but when I'm doing this:
# btrfs subvolume create /.snapshots
Create subvolume '//.snapshots'
it works

and this is what I see in the subvolumes list:
ID 3541 gen 175955 parent 3540 top level 3540 path .snapshots

and then I can create a snapshot with snapper:
# snapper -c root create --description "test"

but snapper starts numbering from 1 again which I don't really like. I
would like to keep the previous snapshots and continue the numbering
after the last restored snapshot (1594).

This is how my fstab looks like now:

# /etc/fstab: static file system information
#
# <file system>                                 <dir>           <type>
         <options>
                                  <dump>  <pas$
# /dev/sdd6 LABEL=ROOT
UUID=...567940c58ea6       /                       btrfs
noatime,nodiratime,compress=lzo,ssd,space_cache,subvolid=257,subvol=/@
                 0       1

# /dev/sdd5 LABEL=BOOT
UUID=...bfb2cdbaf627       /boot                   ext4
relatime,data=ordered,errors=remount-ro
                 0       1

# /dev/sdc1 LABEL=home
UUID=...f1e163883d2b       /home                   ext4
relatime,stripe=32750,data=ordered,errors=remount-ro
                 0       2

# /dev/sdd6 LABEL=ROOT
UUID=...567940c58ea6       /var/cache/pacman/pkg   btrfs
noatime,nodiratime,compress=lzo,ssd,space_cache,subvolid=258,subvol=/@pkg
              0       0

# /dev/sdd6 LABEL=ROOT
UUID=...567940c58ea6       /tmp                    btrfs
noatime,nodiratime,compress=lzo,ssd,space_cache,subvolid=260,subvol=/@tmp
              0       0

# /dev/sdd6 LABEL=ROOT
#UUID=...567940c58ea6      /.snapshots             btrfs
noatime,nodiratime,compress=lzo,ssd,space_cache,subvolid=259,subvol=/@snapshots,subvol=@snapshots
      0       0

# /dev/sdd6 LABEL=ROOT
UUID=...567940c58ea6       /btrfs                  btrfs
noatime,nodiratime,compress=lzo,ssd,space_cache,subvolid=5,subvol=/
                 0       0

Apparently both fstab and btrfs are misconfigured. How can I configure
them correctly?

> It may be possible to move @_old/.snapshots into @/.snapshots, although
> this breaks parent-child relationships those old snapshots cannot be
> cleaned up without removing old root completely.

How? Do you mean with send / receive?