On Thu, Feb 8, 2018 at 5:32 AM, Andrei Borzenkov <arvidj...@gmail.com> wrote: > 08.02.2018 06:03, Chris Murphy пишет: >> On Wed, Feb 7, 2018 at 6:26 PM, Nick Gilmour <nickefo...@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? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html