Re: rollback to a snapshot and delete old top volume - missing of "@"

2016-07-09 Thread Chris Murphy 
On Fri, Jul 8, 2016 at 11:30 PM, Andrei Borzenkov  wrote:
> 09.07.2016 00:50, Chris Murphy пишет:
>>>
>>> Instead those utilities should employ rootflags=subvol or subvolid to
>>> explicitly use a particular fs tree for rootfs, rather that hide this
>>> fact by using subvolume set-default.
>>
>> The only distro installer I know that works this way out of the box is
>> Fedora/Red Hat's Anaconda. It leaves the default subvolume as 5, but
>> does not install the OS there. Instead each mountpoint is created as a
>> subvolume in that top level, and rootflags kernel parameter and fstab
>> are used to assemble those subvolumes per the FHS virtually. It's
>> completely discoverable, you can follow each step along the way, it's
>> not obscured.
>>
>> The additional benefit is no nested subvolumes.
>>
>
> Does it use grub2? Where /boot/grub is located - on one of those
> snapshots or on partition outside of btrfs control?

GRUB yes. The installer only permits /boot on ext4 due an ancient
grubby (not GRUB) bug [1]. It's not dissimilar to openSUSE where /boot
is on ext4, and Btrfs ends up on encrypted LVM, if you choose to
encrypt. It's rather head shaking but that's the state of affairs.

> Does it support booting from previous read-only snapshot directly and/or
> rollback to previous snapshot?

Not by default. Snapper is in the repos.

It looks like the future of rollbacks on Fedora is to not do snapshots
at all, but to deploy binaries using rpm-ostree which provides atomic
OS updates on any file system. The update is only ever applied to a
new tree, not the currently active tree, so if the update fails that
new tree is just deleted, it's never even attempted for reboot. Some
of the directories, most notably /usr, are always read-only. Basically
this is a kind of stateless and therefore resettable machine. As far
as I know there are no optimizations for Btrfs, where either snapshots
or reflinks could be employed instead of depending on hardlinks.


-- 
Chris Murphy
--
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

Re: rollback to a snapshot and delete old top volume - missing of "@"

2016-07-08 Thread Andrei Borzenkov 
09.07.2016 00:50, Chris Murphy пишет:
>>
>> Instead those utilities should employ rootflags=subvol or subvolid to
>> explicitly use a particular fs tree for rootfs, rather that hide this
>> fact by using subvolume set-default.
> 
> The only distro installer I know that works this way out of the box is
> Fedora/Red Hat's Anaconda. It leaves the default subvolume as 5, but
> does not install the OS there. Instead each mountpoint is created as a
> subvolume in that top level, and rootflags kernel parameter and fstab
> are used to assemble those subvolumes per the FHS virtually. It's
> completely discoverable, you can follow each step along the way, it's
> not obscured.
> 
> The additional benefit is no nested subvolumes.
> 

Does it use grub2? Where /boot/grub is located - on one of those
snapshots or on partition outside of btrfs control?

Does it support booting from previous read-only snapshot directly and/or
rollback to previous snapshot?
--
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

Re: rollback to a snapshot and delete old top volume - missing of "@"

2016-07-08 Thread Chris Murphy 
On Thu, Jul 7, 2016 at 11:40 AM, Chris Murphy  wrote:
> On Thu, Jul 7, 2016 at 10:01 AM, Henk Slager  wrote:
>
>> What the latest debian likes as naming convention I dont know, but in
>> openSuSE @ is a directory in the toplevel volume (ID=5 or ID=0 as
>> alias) and that directory contains subvolumes.
>
> No, opensuse doesn't use @ at all. They use a subvolume called
> .snapshots to contain snapper snapshots.

OK this has changed in openSUSE Tumbleweed. It does create an @
subvolume into which all other subvolumes are created including
.snapshots.

0:install:/mnt # btrfs sub list -t /mnt/
IDgentop levelpath
------
257315   @
25812257@/.snapshots
25937258@/.snapshots/1/snapshot
26014257@/boot/grub2/i386-pc
26115257@/boot/grub2/x86_64-efi
26216257@/opt
26317257@/srv
26418257@/tmp
26519257@/usr/local
26635257@/var/cache
26721257@/var/crash
26823257@/var/lib/libvirt/images
26923257@/var/lib/mailman
27025257@/var/lib/mariadb
27126257@/var/lib/mysql
27226257@/var/lib/named
27328257@/var/lib/pgsql
27435257@/var/log
27529257@/var/opt
27630257@/var/spool
27735257@/var/tmp

The installation time rootfs is
0:install:/mnt # mount | grep btrfs
/dev/vda2 on /mnt type btrfs
(rw,relatime,space_cache,subvolid=259,subvol=/@/.snapshots/1/snapshot)

I don't really understand the point of this additional layer of nesting under @.

I didn't test if it's still changing the default subvolume, rather
than using rootflags=subvol or subvolid.



-- 
Chris Murphy
--
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

Re: rollback to a snapshot and delete old top volume - missing of "@"

2016-07-08 Thread Henk Slager 
On Fri, Jul 8, 2016 at 11:50 PM, Chris Murphy  wrote:
> On Fri, Jul 8, 2016 at 3:39 PM, Chris Murphy  wrote:
>> On Fri, Jul 8, 2016 at 2:08 PM, Kai Herlemann  wrote:
>>
>>> If here any developers read along: I'd like to suggest that there's
>>> automatically made a subvolume "@" by default, which is set as default
>>> subvolume, or a tip to the distribution, that it would made sense to do that
>>> with the installation. It would protect other users against confusion and
>>> work like I had it.
>>
>> I think that upstream won't do that or recommend it. There is already
>> a subvolume created at mkfs time, that's subvolid=5 (a.k.a. 0) and it
>> is set as the default subvolume. I don't see the point in having two
>> of them. If you want it, make it. If your distro wants it, it should
>> be done in the installer, not mkfs.
>>
>> Further I think it's inappropriate to take 'btrfs sub set-default'
>> away from the user. That is a user owned setting. It is not OK for
>> some utility to assert domain over that setting, and depend on it for
>> proper booting. It makes the entire boot process undiscoverable,
>> breaks self-describing boot process which are simpler to understand
>> and troubleshoot, in favor of secret decoder ring booting that now
>> requires even more esoteric knowledge on the part of users. So I think
>> it's a bad design.
>>
>> Instead those utilities should employ rootflags=subvol or subvolid to
>> explicitly use a particular fs tree for rootfs, rather that hide this
>> fact by using subvolume set-default.
>
> The only distro installer I know that works this way out of the box is
> Fedora/Red Hat's Anaconda. It leaves the default subvolume as 5, but
> does not install the OS there. Instead each mountpoint is created as a
> subvolume in that top level, and rootflags kernel parameter and fstab
> are used to assemble those subvolumes per the FHS virtually. It's
> completely discoverable, you can follow each step along the way, it's
> not obscured.
>
> The additional benefit is no nested subvolumes.
>
> A possible improvement for those distros that will likely continue
> doing things the way they are, would be if the kernel code stated what
> fs tree ID was being mounted when the default subvolume is not 5, and
> neither subvol nor subvolid mount options were used. *shrug*

On a running system as non-root:
$ mount | grep "on / type btrfs"
/dev/sda1 on / type btrfs
(rw,noatime,compress=lzo,ssd,discard,space_cache,subvolid=2429,subvol=/@/latestrootfs)

On an image of a disk or some separate disk with rootfs tree mounted
somewhere, I agree that it might look 'hidden'; you will have to
realize that the filesystem is Btrfs and that the default subvol might
not be 5, but  btrfs sub list / gives the answer to what more is in
the pool.
--
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

Re: rollback to a snapshot and delete old top volume - missing of "@"

2016-07-08 Thread Chris Murphy 
On Fri, Jul 8, 2016 at 3:39 PM, Chris Murphy  wrote:
> On Fri, Jul 8, 2016 at 2:08 PM, Kai Herlemann  wrote:
>
>> If here any developers read along: I'd like to suggest that there's
>> automatically made a subvolume "@" by default, which is set as default
>> subvolume, or a tip to the distribution, that it would made sense to do that
>> with the installation. It would protect other users against confusion and
>> work like I had it.
>
> I think that upstream won't do that or recommend it. There is already
> a subvolume created at mkfs time, that's subvolid=5 (a.k.a. 0) and it
> is set as the default subvolume. I don't see the point in having two
> of them. If you want it, make it. If your distro wants it, it should
> be done in the installer, not mkfs.
>
> Further I think it's inappropriate to take 'btrfs sub set-default'
> away from the user. That is a user owned setting. It is not OK for
> some utility to assert domain over that setting, and depend on it for
> proper booting. It makes the entire boot process undiscoverable,
> breaks self-describing boot process which are simpler to understand
> and troubleshoot, in favor of secret decoder ring booting that now
> requires even more esoteric knowledge on the part of users. So I think
> it's a bad design.
>
> Instead those utilities should employ rootflags=subvol or subvolid to
> explicitly use a particular fs tree for rootfs, rather that hide this
> fact by using subvolume set-default.

The only distro installer I know that works this way out of the box is
Fedora/Red Hat's Anaconda. It leaves the default subvolume as 5, but
does not install the OS there. Instead each mountpoint is created as a
subvolume in that top level, and rootflags kernel parameter and fstab
are used to assemble those subvolumes per the FHS virtually. It's
completely discoverable, you can follow each step along the way, it's
not obscured.

The additional benefit is no nested subvolumes.

A possible improvement for those distros that will likely continue
doing things the way they are, would be if the kernel code stated what
fs tree ID was being mounted when the default subvolume is not 5, and
neither subvol nor subvolid mount options were used. *shrug*


-- 
Chris Murphy
--
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

Re: rollback to a snapshot and delete old top volume - missing of "@"

2016-07-08 Thread Chris Murphy 
On Fri, Jul 8, 2016 at 2:08 PM, Kai Herlemann  wrote:

> If here any developers read along: I'd like to suggest that there's
> automatically made a subvolume "@" by default, which is set as default
> subvolume, or a tip to the distribution, that it would made sense to do that
> with the installation. It would protect other users against confusion and
> work like I had it.

I think that upstream won't do that or recommend it. There is already
a subvolume created at mkfs time, that's subvolid=5 (a.k.a. 0) and it
is set as the default subvolume. I don't see the point in having two
of them. If you want it, make it. If your distro wants it, it should
be done in the installer, not mkfs.

Further I think it's inappropriate to take 'btrfs sub set-default'
away from the user. That is a user owned setting. It is not OK for
some utility to assert domain over that setting, and depend on it for
proper booting. It makes the entire boot process undiscoverable,
breaks self-describing boot process which are simpler to understand
and troubleshoot, in favor of secret decoder ring booting that now
requires even more esoteric knowledge on the part of users. So I think
it's a bad design.

Instead those utilities should employ rootflags=subvol or subvolid to
explicitly use a particular fs tree for rootfs, rather that hide this
fact by using subvolume set-default.



-- 
Chris Murphy
--
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

Re: rollback to a snapshot and delete old top volume - missing of "@"

2016-07-08 Thread Kai Herlemann 

Am 07.07.2016 um 19:40 schrieb Chris Murphy:

And very clearly from the OP's output from 'btrfs sub list' there are
no subvolumes with @ in the path, so there is no subvolume @, nor are
there any subvolumes contained in a directory @.

[...]

Anyway the reason why the command fails is stated in the error
message. The system appears to be installed in the top level of the
file system (subvolid=5), and that can't be deleted. First it's the
immutable first subvolume of a Btrfs file system, and second it's
populated with other subvolumes which would inhibit its removal even
if it weren't the top level subvolume.

What can be done is delete the directories in the top level, retaining
the subvolumes that are there.
Thank you, that was it: there was really no subvolume named @ existing. 
Thank you to Henk and Andrei, too.
I didn't believed that, although there was no @ from ot the output of 
"btrfs sub list", because all websites that dealt with this topic and 
which I used for research statet that a subvolume named @ would 
automatically be created (or I misunderstood the sites), and secondly, 
because the ID of the top level volume is in my case 5, and I 
(mis)understand, in cases where's the subvolume "@" automatically 
created, the ID of that subvolume would be also 5.
I created now myself a subvolume "@" on the top level volume, moved then 
all the data from the snapshot, which I used the last days, to the new 
subvolume, and deleted then all data from the top level volume, except 
the sub level volume @ of course, and made previously a backup snapshot 
from the top level volume. Other users who reading later here and want 
to move their data from top level volume should able to do the same.


If here any developers read along: I'd like to suggest that there's 
automatically made a subvolume "@" by default, which is set as default 
subvolume, or a tip to the distribution, that it would made sense to do 
that with the installation. It would protect other users against 
confusion and work like I had it.


Thank you,
Kai
--
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

Re: rollback to a snapshot and delete old top volume - missing of "@"

2016-07-08 Thread Andrei Borzenkov 
07.07.2016 15:17, Kai Herlemann пишет:
> Hi,
> 
> I want to rollback a snapshot and have done this by execute "btrfs sub
> set-default / 618".
> Now I want to delete the old top volume to save space, but google and
> manuals didn't helped.
> 
> I mounted for the following the root volume at /mnt/gparted with
> subvolid=0, subvol=/ has the same effect.
> Usually, the top volume is saved in /@, so I would be able to delete it
> by execute "btrfs sub delete /@" (or move at first @ to @_badroot and
> the snapshot to @). But that isn't possible, the output of that command
> is "ERROR: cannot access subvolume /@: No such file or directory".
> I've posted the output of "btrfs sub list /mnt/gparted" at
> http://pastebin.com/r7WNbJq8. As you can see, there's no subvolume named @.
> 
> I have the same problem with my /home/ partition.
> 
> Output of "uname -a" (self-compiled kernel):
> Linux debian-linux 4.1.26 #1 SMP Wed Jun 8 18:40:04 CEST 2016 x86_64
> GNU/Linux
> 

You need to ask on your distribution list; this is really not a question
of btrfs but rather how distribution manages snapshots.

But if you originally installed in top level subvolume, then you have no
way to delete it. You may try to manually clean content of top level
subvolume if you need to free space.

That was initial implementation done by (open)SUSE and they changed it
later to install in subvolume from the very start. But information you
provided is not enough to know how system was installed originally.
--
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

Re: rollback to a snapshot and delete old top volume - missing of "@"

2016-07-07 Thread Henk Slager 
On Thu, Jul 7, 2016 at 7:40 PM, Chris Murphy  wrote:
> On Thu, Jul 7, 2016 at 10:01 AM, Henk Slager  wrote:
>
>> What the latest debian likes as naming convention I dont know, but in
>> openSuSE @ is a directory in the toplevel volume (ID=5 or ID=0 as
>> alias) and that directory contains subvolumes.

Sorry, I mixed-up latest opensuse and my own adaptions to older installations.

> No, opensuse doesn't use @ at all. They use a subvolume called
> .snapshots to contain snapper snapshots.

On current fresh install "openSUSE Tumbleweed (20160703) (x86_64)" you get this:

# btrfs sub list /
ID 257 gen 24369 top level 5 path @
ID 258 gen 24369 top level 257 path @/.snapshots
ID 259 gen 24369 top level 258 path @/.snapshots/1/snapshot
ID 265 gen 25404 top level 257 path @/tmp
ID 267 gen 24369 top level 257 path @/var/cache
ID 268 gen 20608 top level 257 path @/var/crash
ID 269 gen 20608 top level 257 path @/var/lib/libvirt/images
ID 270 gen 3903 top level 257 path @/var/lib/mailman
ID 271 gen 2996 top level 257 path @/var/lib/mariadb
ID 272 gen 3904 top level 257 path @/var/lib/mysql
ID 273 gen 3903 top level 257 path @/var/lib/named
ID 274 gen 8 top level 257 path @/var/lib/pgsql
ID 275 gen 25404 top level 257 path @/var/log
ID 276 gen 20611 top level 257 path @/var/opt
ID 277 gen 25404 top level 257 path @/var/spool
ID 278 gen 24369 top level 257 path @/var/tmp
ID 300 gen 10382 top level 258 path @/.snapshots/15/snapshot
[..]

@ is the only thing in the toplevel

I have changed it a bit for this particular PC, so that more is in one subvol.
Just after default install, subvol with ID 259 is made default and rw

I had also updated my older linux installs a bit like this, but with @
a dir, not a subvol, so that at least I can easily swap
'latestroofs' subvol with something else. My interpretation of the
OP's report was that he basically wants something like that too.

> On a system using snapper, its snapshots should probably be deleted
> via snapper so it's aware of the state change.

You can do that, but also with btrfs sub del in re-organisation
actions like described here. If you delete the .xml files in the
subvol .snapshots, it starts counting from 1 again. Changing the
latest .xml file can make it start counting from some higher number if
that is important for many-months history for example.

> And very clearly from the OP's output from 'btrfs sub list' there are
> no subvolumes with @ in the path, so there is no subvolume @, nor are
> there any subvolumes contained in a directory @.
>
> Assuming the posted output from btrfs sub list is the complete output,
> .snapshots is a directory and there are three subvolumes in it. I
> suspect the OP is unfamiliar with snapper conventions and is trying to
> delete a snapshot outside of snapper, and is used to some other
> (Debian or Ubuntu) convention where snapshots somehow relate to @,
> which is a mimicking of how ZFS does things.
>
> Anyway the reason why the command fails is stated in the error
> message. The system appears to be installed in the top level of the
> file system (subvolid=5), and that can't be deleted. First it's the
> immutable first subvolume of a Btrfs file system, and second it's
> populated with other subvolumes which would inhibit its removal even
> if it weren't the top level subvolume.
>
> What can be done is delete the directories in the top level, retaining
> the subvolumes that are there.

Indeed, yes, as a last cleanup step.
--
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

Re: rollback to a snapshot and delete old top volume - missing of "@"

2016-07-07 Thread Chris Murphy 
On Thu, Jul 7, 2016 at 10:01 AM, Henk Slager  wrote:

> What the latest debian likes as naming convention I dont know, but in
> openSuSE @ is a directory in the toplevel volume (ID=5 or ID=0 as
> alias) and that directory contains subvolumes.

No, opensuse doesn't use @ at all. They use a subvolume called
.snapshots to contain snapper snapshots.

On a system using snapper, its snapshots should probably be deleted
via snapper so it's aware of the state change.

And very clearly from the OP's output from 'btrfs sub list' there are
no subvolumes with @ in the path, so there is no subvolume @, nor are
there any subvolumes contained in a directory @.

Assuming the posted output from btrfs sub list is the complete output,
.snapshots is a directory and there are three subvolumes in it. I
suspect the OP is unfamiliar with snapper conventions and is trying to
delete a snapshot outside of snapper, and is used to some other
(Debian or Ubuntu) convention where snapshots somehow relate to @,
which is a mimicking of how ZFS does things.

Anyway the reason why the command fails is stated in the error
message. The system appears to be installed in the top level of the
file system (subvolid=5), and that can't be deleted. First it's the
immutable first subvolume of a Btrfs file system, and second it's
populated with other subvolumes which would inhibit its removal even
if it weren't the top level subvolume.

What can be done is delete the directories in the top level, retaining
the subvolumes that are there.




-- 
Chris Murphy
--
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

Re: rollback to a snapshot and delete old top volume - missing of "@"

2016-07-07 Thread Henk Slager 
On Thu, Jul 7, 2016 at 2:17 PM, Kai Herlemann  wrote:
> Hi,
>
> I want to rollback a snapshot and have done this by execute "btrfs sub
> set-default / 618".
maybe just a typo here, command syntax is:
# sudo btrfs sub set-default
btrfs subvolume set-default: too few arguments
usage: btrfs subvolume set-default  

   Set the default subvolume of a filesystem

> Now I want to delete the old top volume to save space, but google and
> manuals didn't helped.
>
> I mounted for the following the root volume at /mnt/gparted with subvolid=0,
> subvol=/ has the same effect.
> Usually, the top volume is saved in /@, so I would be able to delete it by
> execute "btrfs sub delete /@" (or move at first @ to @_badroot and the
> snapshot to @). But that isn't possible, the output of that command is
> "ERROR: cannot access subvolume /@: No such file or directory".
> I've posted the output of "btrfs sub list /mnt/gparted" at
> http://pastebin.com/r7WNbJq8. As you can see, there's no subvolume named @.

I think one or the other commandtyping didn't have its expected
effect, just to make sure I get the right state, can you do:

mkdir -p /fsroot
mount -o subvolid=0 UUID= /fsroot
btrfs sub list /fsroot
btrfs subvolume get-default /

What the latest debian likes as naming convention I dont know, but in
openSuSE @ is a directory in the toplevel volume (ID=5 or ID=0 as
alias) and that directory contains subvolumes. You can do whatever you
like best, but at least make sure you have mount entries in fstab
subvolumes like var/cache/apt and usr/src, otherwise this magnificent
rootfstree snapshotting gets you into trouble.

I think your current default subvolume is still 5, so you would need:

fstab:
UUID=/btrfsdefaults   0 0
#UUID=/homebtrfsdefaults,subvol=@/home   0 0
UUID=/usr/srcbtrfs
defaults,subvol=@/usr/src   0 0
UUID=/var/cache/aptbtrfs
defaults,subvol=@/var/cache/apt   0 0
UUID=/.snapshotsbtrfs
defaults,subvol=@/.snapshots   0 0
UUID=/fsrootbtrfsnoauto,subvolid=0   0 0


mkdir -p /fsroot
mount -o subvolid=0 UUID= /fsroot

mkdir -p /usr/src
mkdir -p /var/cache/apt
mkdir -p /.snapshots

mkdir -p /fsroot/@/usr
mkdir -p /fsroot/@/var/cache

btrfs sub create /fsroot/@/usr/src
btrfs sub create /fsroot/@/var/cache/apt
btrfs sub create /fsroot/@/.snapshots

#snapshots might need different, the proposed one works at least for snapper

btrfs sub snap / /fsroot/@/latestrootfs
btrfs sub set-default  /
btrfs fi sync /

#for home fs is it similar as for root fs

reboot

You can then when you want rollback, set a snapshot to rw  (or rename
latestrootfs, snapshot snapshot to that name ) and make it default
subvol and reboot (or maybe also do some temp chroot tricks, I have
not tried that)

> I have the same problem with my /home/ partition.
>
> Output of "uname -a" (self-compiled kernel):
> Linux debian-linux 4.1.26 #1 SMP Wed Jun 8 18:40:04 CEST 2016 x86_64
> GNU/Linux
>
> Output of "btrfs --version":
> btrfs-progs v4.5.2
>
> Output of "btrfs fi show":
> Label: none  uuid: f778877c-d50b-48c8-8951-6635c6e23c61
>   Total devices 1 FS bytes used 43.70GiB
>   devid1 size 55.62GiB used 47.03GiB path /dev/sda1
>
> Output of "btrfs fi df /":
> Data, single: total=44.00GiB, used=42.48GiB
> System, single: total=32.00MiB, used=16.00KiB
> Metadata, single: total=3.00GiB, used=1.22GiB
> GlobalReserve, single: total=416.00MiB, used=0.00B
>
> Output of dmesg attached.
>
> Thank you,
> Kai
>
--
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

rollback to a snapshot and delete old top volume - missing of "@"

2016-07-07 Thread Kai Herlemann 

Hi,

I want to rollback a snapshot and have done this by execute "btrfs sub 
set-default / 618".
Now I want to delete the old top volume to save space, but google and 
manuals didn't helped.


I mounted for the following the root volume at /mnt/gparted with 
subvolid=0, subvol=/ has the same effect.
Usually, the top volume is saved in /@, so I would be able to delete it 
by execute "btrfs sub delete /@" (or move at first @ to @_badroot and 
the snapshot to @). But that isn't possible, the output of that command 
is "ERROR: cannot access subvolume /@: No such file or directory".
I've posted the output of "btrfs sub list /mnt/gparted" at 
http://pastebin.com/r7WNbJq8. As you can see, there's no subvolume named @.


I have the same problem with my /home/ partition.

Output of "uname -a" (self-compiled kernel):
Linux debian-linux 4.1.26 #1 SMP Wed Jun 8 18:40:04 CEST 2016 x86_64 
GNU/Linux


Output of "btrfs --version":
btrfs-progs v4.5.2

Output of "btrfs fi show":
Label: none  uuid: f778877c-d50b-48c8-8951-6635c6e23c61
  Total devices 1 FS bytes used 43.70GiB
  devid1 size 55.62GiB used 47.03GiB path /dev/sda1

Output of "btrfs fi df /":
Data, single: total=44.00GiB, used=42.48GiB
System, single: total=32.00MiB, used=16.00KiB
Metadata, single: total=3.00GiB, used=1.22GiB
GlobalReserve, single: total=416.00MiB, used=0.00B

Output of dmesg attached.

Thank you,
Kai

[0.00] microcode: CPU0 microcode updated early to revision 0xe, date = 2013-06-26
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 4.1.26 (root@debian-linux) (gcc version 5.3.1 20160528 (Debian 5.3.1-21) ) #1 SMP Wed Jun 8 18:40:04 CEST 2016
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.1.26 root=UUID=f778877c-d50b-48c8-8951-6635c6e23c61 ro resume=UUID=9be0bf62-859d-42cb-b075-4bd31f41c53d init=/lib/systemd/systemd
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009cfff] usable
[0.00] BIOS-e820: [mem 0x0009d000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x9f680fff] usable
[0.00] BIOS-e820: [mem 0x9f681000-0x9f6befff] reserved
[0.00] BIOS-e820: [mem 0x9f6bf000-0x9f735fff] usable
[0.00] BIOS-e820: [mem 0x9f736000-0x9f7befff] ACPI NVS
[0.00] BIOS-e820: [mem 0x9f7bf000-0x9f7defff] usable
[0.00] BIOS-e820: [mem 0x9f7df000-0x9f7fefff] ACPI data
[0.00] BIOS-e820: [mem 0x9f7ff000-0x9f7f] usable
[0.00] BIOS-e820: [mem 0x9f80-0x9fff] reserved
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfeb0-0xfeb03fff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed1-0xfed13fff] reserved
[0.00] BIOS-e820: [mem 0xfed18000-0xfed19fff] reserved
[0.00] BIOS-e820: [mem 0xfed1b000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xffe8-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x000157ff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.6 present.
[0.00] DMI: eMachineseME730G /eME730G , BIOS V1.23 04/25/2011
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] AGP: No AGP bridge found
[0.00] e820: last_pfn = 0x158000 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask F8000 write-back
[0.00]   1 base 0FFE0 mask FFFE0 write-protect
[0.00]   2 base 08000 mask FE000 write-back
[0.00]   3 base 09F80 mask FFF80 uncachable
[0.00]   4 base 1 mask FC000 write-back
[0.00]   5 base 14000 mask FF000 write-back
[0.00]   6 base 15000 mask FF800 write-back
[0.00]   7 disabled
[0.00] PAT configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- UC  
[0.00] e820: last_pfn = 0x9f800 max_arch_pfn = 0x4
[0.00] Base memory trampoline at [88097000] 97000 size 24576
[0.00] init_memory_mapping: [mem