SLES 11 SP4: can't mount btrfs

SLES 11 SP4: can't mount btrfs

[Lentes, Bernd]

Hi,

this is the continuation of a thread i started on a SLES forum (https://forums.suse.com/showthread.php?10109-lv-with-btrfs-corrupt-some-tips-please), but i think this is the more appropriate place.
I have a SLES 11 SP4 with a btrfs on top of a logical volume i can't mount anymore. The host was fenced in a two-node cluster, and the boot procedure can't mount the lv, and i reside in simple shell (i assume the one from initrd).

I have a second nearly identical node, so i can give you some information:

ha-idg-2:/etc/corosync # uname -a
Linux ha-idg-2 3.0.101-84-default #1 SMP Tue Oct 18 10:32:51 UTC 2016 (15251d6) x86_64 x86_64 x86_64 GNU/Linux

ha-idg-2:/etc/corosync # rpm -qa|grep -i btrfs
libbtrfs0-3.18.2-0.40.48
btrfsmaintenance-0.1-3.1
btrfsprogs-3.18.2-0.40.48

I try to follow the recommendations on https://btrfs.wiki.kernel.org/index.php/Problem_FAQ.

I booted the system now with knoppix 8.1, which has kernel 4.12.7 and btrfs-progs 4.7.3-1. Is that ok ?
I tried:

mount /dev/vg1/lv_root /lv_root -o recovery,ro
and got:
mount: wrong fs type, bad option, bad superblock on /dev/mapper/vg1-lv_root,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.


and got via dmesg:
[92518.955408] BTRFS info (device dm-0): disk space caching is enabled
[92518.990561] BTRFS error (device dm-0): parent transid verify failed on 196314759168 wanted 793932 found 793496
[92518.990911] BTRFS error (device dm-0): parent transid verify failed on 196314759168 wanted 793932 found 793496
[92518.990919] BTRFS error (device dm-0): failed to read block groups: -5
[92519.070084] BTRFS error (device dm-0): open_ctree failed

next step:

root@Microknoppix:~# btrfs device scan
Scanning for Btrfs filesystems
root@Microknoppix:~#

no result !?!

Now i changed to https://btrfs.wiki.kernel.org/index.php/Restore:

btrfs restore -smSvi /dev/vg1/lv_root /mnt/idg-2/SysAdmin_AG_Wurst/recover/ha-idg-1/ |tee /mnt/idg-2/SysAdmin_AG_Wurst/recover/ha-idg-1/recover.log

I just started it. I get lines like:
offset is 61440
offset is 98304
offset is 4096
offset is 143360
offset is 8192
offset is 184320

or

Error searching /mnt/idg-2/SysAdmin_AG_Wurst/recover/ha-idg-1/@/tmp/localhpsum/assets/doc/help/en
Error searching /mnt/idg-2/SysAdmin_AG_Wurst/recover/ha-idg-1/@/tmp/localhpsum/assets/doc/help/ja/images/callouts

What does that mean ?


Bernd



-- 
Bernd Lentes 

Systemadministration 
institute of developmental genetics 
Gebäude 35.34 - Raum 208 
HelmholtzZentrum München 
bernd.lentes@helmholtz-muenchen.de 
phone: +49 (0)89 3187 1241 
fax: +49 (0)89 3187 2294 

no backup - no mercy
 

Helmholtz Zentrum Muenchen
Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
Ingolstaedter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen
Registergericht: Amtsgericht Muenchen HRB 6466
USt-IdNr: DE 129521671

RE: SLES 11 SP4: can't mount btrfs

[Lentes, Bernd]

> -----Original Message-----
> From: linux-btrfs-owner@vger.kernel.org [mailto:linux-btrfs-
> owner@vger.kernel.org] On Behalf Of Lentes, Bernd
> Sent: Thursday, October 19, 2017 7:44 PM
> To: Btrfs ML <linux-btrfs@vger.kernel.org>
> Subject: SLES 11 SP4: can't mount btrfs
>
> Hi,
>
> this is the continuation of a thread i started on a SLES forum
> (https://forums.suse.com/showthread.php?10109-lv-with-btrfs-corrupt-
> some-tips-please), but i think this is the more appropriate place.
> I have a SLES 11 SP4 with a btrfs on top of a logical volume i can't mount
> anymore. The host was fenced in a two-node cluster, and the boot
> procedure can't mount the lv, and i reside in simple shell (i assume the
> one from initrd).
>
> I have a second nearly identical node, so i can give you some information:
>
> ha-idg-2:/etc/corosync # uname -a
> Linux ha-idg-2 3.0.101-84-default #1 SMP Tue Oct 18 10:32:51 UTC 2016
> (15251d6) x86_64 x86_64 x86_64 GNU/Linux
>
> ha-idg-2:/etc/corosync # rpm -qa|grep -i btrfs
> libbtrfs0-3.18.2-0.40.48
> btrfsmaintenance-0.1-3.1
> btrfsprogs-3.18.2-0.40.48
>
> I try to follow the recommendations on
> https://btrfs.wiki.kernel.org/index.php/Problem_FAQ.
>
> I booted the system now with knoppix 8.1, which has kernel 4.12.7 and
> btrfs-progs 4.7.3-1. Is that ok ?
> I tried:
>
> mount /dev/vg1/lv_root /lv_root -o recovery,ro and got:
> mount: wrong fs type, bad option, bad superblock on /dev/mapper/vg1-
> lv_root,
>        missing codepage or helper program, or other error
>
>        In some cases useful info is found in syslog - try
>        dmesg | tail or so.
>
>
> and got via dmesg:
> [92518.955408] BTRFS info (device dm-0): disk space caching is enabled
> [92518.990561] BTRFS error (device dm-0): parent transid verify failed on
> 196314759168 wanted 793932 found 793496 [92518.990911] BTRFS error
> (device dm-0): parent transid verify failed on 196314759168 wanted
> 793932 found 793496 [92518.990919] BTRFS error (device dm-0): failed to
> read block groups: -5 [92519.070084] BTRFS error (device dm-0):
> open_ctree failed
>
> next step:
>
> root@Microknoppix:~# btrfs device scan
> Scanning for Btrfs filesystems
> root@Microknoppix:~#
>
> no result !?!
>
> Now i changed to https://btrfs.wiki.kernel.org/index.php/Restore:
>
> btrfs restore -smSvi /dev/vg1/lv_root /mnt/idg-
> 2/SysAdmin_AG_Wurst/recover/ha-idg-1/ |tee /mnt/idg-
> 2/SysAdmin_AG_Wurst/recover/ha-idg-1/recover.log
>
> I just started it. I get lines like:
> offset is 61440
> offset is 98304
> offset is 4096
> offset is 143360
> offset is 8192
> offset is 184320
>
> or
>
> Error searching /mnt/idg-2/SysAdmin_AG_Wurst/recover/ha-idg-
> 1/@/tmp/localhpsum/assets/doc/help/en
> Error searching /mnt/idg-2/SysAdmin_AG_Wurst/recover/ha-idg-
> 1/@/tmp/localhpsum/assets/doc/help/ja/images/callouts
>
> What does that mean ?
>
>
> Bernd
>

The process does not continue, but it's still visible with ps. Also top does 
not show that this process is consuming resources. iotop does not show any 
activity on my lv.
My logfile is unchanged for two hours. Does that mean that btrfs gave up or 
is it still struggling ?

Bernd
 

Helmholtz Zentrum Muenchen
Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
Ingolstaedter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen
Registergericht: Amtsgericht Muenchen HRB 6466
USt-IdNr: DE 129521671

Re: SLES 11 SP4: can't mount btrfs

[Chris Murphy]

On Thu, Oct 19, 2017 at 6:43 PM, Lentes, Bernd
<bernd.lentes@helmholtz-muenchen.de> wrote:
> Hi,
>
> this is the continuation of a thread i started on a SLES forum (https://forums.suse.com/showthread.php?10109-lv-with-btrfs-corrupt-some-tips-please), but i think this is the more appropriate place.

Maybe, but as this is SLES, you're effectively paying for support, and
it's actually better to open a support instance, in my opinion. Btrfs
is not just supported by SUSE, it's the default file system.


> I booted the system now with knoppix 8.1, which has kernel 4.12.7 and btrfs-progs 4.7.3-1. Is that ok ?

Since it's SLES, you have to use whatever they recommend. I don't know
Knoppix kernels, so I can't say with any certainty what's in 4.12.7,
but 4.7.3 for btrfs-progs is rather old. There have been many
improvements since that time, in particular with 'btrfs check'

What I usually recommend is getting a current version of Fedora
because it'll have very recent kernels, the gotcha being that to also
get recent btrfs-progs you have to get a copy of Rawhide or like right
now you could use Fedora 27 Beta which is decently safe and also has
new kernel and progs, and in terms of Btrfs of block level stuff we
care about, Fedora runs pretty much identical to to kernel.org code,
so it's not like developers have to use secret decoder rings to know
what the kernel version really means.
https://getfedora.org/en/workstation/prerelease/



> I tried:
>
> mount /dev/vg1/lv_root /lv_root -o recovery,ro
> and got:
> mount: wrong fs type, bad option, bad superblock on /dev/mapper/vg1-lv_root,
>        missing codepage or helper program, or other error
>
>        In some cases useful info is found in syslog - try
>        dmesg | tail or so.
>
>
> and got via dmesg:
> [92518.955408] BTRFS info (device dm-0): disk space caching is enabled
> [92518.990561] BTRFS error (device dm-0): parent transid verify failed on 196314759168 wanted 793932 found 793496
> [92518.990911] BTRFS error (device dm-0): parent transid verify failed on 196314759168 wanted 793932 found 793496
> [92518.990919] BTRFS error (device dm-0): failed to read block groups: -5
> [92519.070084] BTRFS error (device dm-0): open_ctree failed





>
> next step:
>
> root@Microknoppix:~# btrfs device scan
> Scanning for Btrfs filesystems
> root@Microknoppix:~#
>
> no result !?!

Normal. Scan just tells btrfs to go look for devices, it doesn't
return a result.

>
> Now i changed to https://btrfs.wiki.kernel.org/index.php/Restore:
>
> btrfs restore -smSvi /dev/vg1/lv_root /mnt/idg-2/SysAdmin_AG_Wurst/recover/ha-idg-1/ |tee /mnt/idg-2/SysAdmin_AG_Wurst/recover/ha-idg-1/recover.log
>
> I just started it. I get lines like:
> offset is 61440
> offset is 98304
> offset is 4096
> offset is 143360
> offset is 8192
> offset is 184320
>
> or
>
> Error searching /mnt/idg-2/SysAdmin_AG_Wurst/recover/ha-idg-1/@/tmp/localhpsum/assets/doc/help/en
> Error searching /mnt/idg-2/SysAdmin_AG_Wurst/recover/ha-idg-1/@/tmp/localhpsum/assets/doc/help/ja/images/callouts
>
> What does that mean ?

btrfs restore is pretty much just a brute force hammer for scraping
data off a volume, pretty much it either works or doesn't work,
there's not a lot of in between.

You're probably better off doing both 'btrfs check' and 'btrfs check
--mode=lowmem' without the --repair option, and report back what both
results are.

You can cancel the restore that's in progress is sounds like it's
still doing something, but stuck in a loop maybe. I'm not sure if
there are many restore fixes since btrfs-progs 4.7 though; you could
check the changelog which is in the wiki.

I think the way forward is to get a little more information for
developers, and then maybe they'll be able to say whether --repair is
safe to use or not in your situation.

In any case, report back what you find out. It'd be useful.

-- 
Chris Murphy

Re: SLES 11 SP4: can't mount btrfs

[Andrei Borzenkov]

19.10.2017 23:04, Chris Murphy пишет:
> Btrfs
> is not just supported by SUSE, it's the default file system.
> 

It is default choice for root starting with SLES12, not in SLES11. But
yes, it should still be supported.

I do not hold my breath though. For all I can tell transid errors are
usually fatal and if this is root, it may be easier and faster to just
reinstall.

RE: SLES 11 SP4: can't mount btrfs

[Lentes, Bernd]

> -----Original Message-----
> From: Andrei Borzenkov [mailto:arvidjaar@gmail.com]
> Sent: Friday, October 20, 2017 6:09 AM
> To: Chris Murphy <lists@colorremedies.com>; Lentes, Bernd
> <bernd.lentes@helmholtz-muenchen.de>
> Cc: Btrfs ML <linux-btrfs@vger.kernel.org>
> Subject: Re: SLES 11 SP4: can't mount btrfs
>
> 19.10.2017 23:04, Chris Murphy пишет:
> > Btrfs
> > is not just supported by SUSE, it's the default file system.
> >
>
> It is default choice for root starting with SLES12, not in SLES11. But 
> yes, it
> should still be supported.
>
> I do not hold my breath though. For all I can tell transid errors are 
> usually
> fatal and if this is root, it may be easier and faster to just reinstall.

Hi Andrei,

thanks for that info. So I will not waste my time and restore from a backup. 
Or fresh installation with SLES 12 SP3 on my two cluster nodes, because SLES 
11 SP4 is pretty old and support ends in beginning of 2019.
I also found the culprit for the disaster: the battery from the write-cache 
of the RAID-Controller was empty, I ordered a new one.

Bernd
 

Helmholtz Zentrum Muenchen
Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
Ingolstaedter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen
Registergericht: Amtsgericht Muenchen HRB 6466
USt-IdNr: DE 129521671

RE: SLES 11 SP4: can't mount btrfs

[Lentes, Bernd]

> -----Original Message-----
> From: linux-btrfs-owner@vger.kernel.org [mailto:linux-btrfs-
> owner@vger.kernel.org] On Behalf Of Lentes, Bernd
> Sent: Friday, October 20, 2017 7:26 PM
> To: Btrfs ML <linux-btrfs@vger.kernel.org>
> Subject: RE: SLES 11 SP4: can't mount btrfs
>
>
> > -----Original Message-----
> > From: Andrei Borzenkov [mailto:arvidjaar@gmail.com]
> > Sent: Friday, October 20, 2017 6:09 AM
> > To: Chris Murphy <lists@colorremedies.com>; Lentes, Bernd
> > <bernd.lentes@helmholtz-muenchen.de>
> > Cc: Btrfs ML <linux-btrfs@vger.kernel.org>
> > Subject: Re: SLES 11 SP4: can't mount btrfs
> >
>
> Hi Andrei,
>
> thanks for that info. So I will not waste my time and restore from a
> backup.
> Or fresh installation with SLES 12 SP3 on my two cluster nodes, because
> SLES
> 11 SP4 is pretty old and support ends in beginning of 2019.
> I also found the culprit for the disaster: the battery from the 
> write-cache
> of the RAID-Controller was empty, I ordered a new one.
>

Is it generally possible to restore a btrfs partition from a tape backup ?
I'm just starting, and I'm asking myself. What is about the subvolumes ?
This information isn't stored in files, but in the fs ? This is not on a 
file-based backup on a tape.

Bernd
 

Helmholtz Zentrum Muenchen
Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
Ingolstaedter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen
Registergericht: Amtsgericht Muenchen HRB 6466
USt-IdNr: DE 129521671

Re: SLES 11 SP4: can't mount btrfs

[Duncan]

Lentes, Bernd posted on Fri, 20 Oct 2017 20:40:15 +0200 as excerpted:

> Is it generally possible to restore a btrfs partition from a tape backup
> ?
> I'm just starting, and I'm asking myself. What is about the subvolumes ?
> This information isn't stored in files, but in the fs ? This is not on a
> file-based backup on a tape.

Yes it's possible to restore a btrfs partition from tape backup, /if/ you 
backed up the partition itself, not just the files on top of it.

Otherwise, as you deduce, you get the files, but not the snapshot history 
or relationship, nor the subvolumes, which will look to normal file-level 
backup software (that is, backup software not designed with btrfs-
specifics like subvolumes, which if it did, would likely use btrfs send/
receive at least optionally) like normal directories.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: SLES 11 SP4: can't mount btrfs

[Lentes, Bernd]

----- Am 21. Okt 2017 um 4:31 schrieb Duncan 1i5t5.duncan@cox.net:

> Lentes, Bernd posted on Fri, 20 Oct 2017 20:40:15 +0200 as excerpted:
> 
>> Is it generally possible to restore a btrfs partition from a tape backup
>> ?
>> I'm just starting, and I'm asking myself. What is about the subvolumes ?
>> This information isn't stored in files, but in the fs ? This is not on a
>> file-based backup on a tape.
> 
> Yes it's possible to restore a btrfs partition from tape backup, /if/ you
> backed up the partition itself, not just the files on top of it.
> 
> Otherwise, as you deduce, you get the files, but not the snapshot history
> or relationship, nor the subvolumes, which will look to normal file-level
> backup software (that is, backup software not designed with btrfs-
> specifics like subvolumes, which if it did, would likely use btrfs send/
> receive at least optionally) like normal directories.
> 
> --

Hi Duncan,

i apprehend that i have just a file based backup. We use EMC Networker (version 8.1 or 8.2), and from what i read in the net i think it
does not support BTRFS. So i have to reinstall, which is maybe not the worst, because i'm thinking about using SLES 11 SP3.

What i know now is that i can't rely on our EMC backup.
What would you propose to backup a complete btrfs partition (https://btrfs.wiki.kernel.org/index.php/Incremental_Backup) ?
We have a NAS with propable enough space, and the servers aren't used heavily over night. So using one of the mentioned tools in a cronjob over night is possible.
Which tool do you recommend ?

Bernd

 

Helmholtz Zentrum Muenchen
Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
Ingolstaedter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen
Registergericht: Amtsgericht Muenchen HRB 6466
USt-IdNr: DE 129521671

Re: SLES 11 SP4: can't mount btrfs

[Adam Borowski]

On Sat, Oct 21, 2017 at 01:46:06PM +0200, Lentes, Bernd wrote:
> ----- Am 21. Okt 2017 um 4:31 schrieb Duncan 1i5t5.duncan@cox.net:
> > Lentes, Bernd posted on Fri, 20 Oct 2017 20:40:15 +0200 as excerpted:
> > 
> >> Is it generally possible to restore a btrfs partition from a tape backup
> >> ?
> >> I'm just starting, and I'm asking myself. What is about the subvolumes ?
> >> This information isn't stored in files, but in the fs ? This is not on a
> >> file-based backup on a tape.
> > 
> > Yes it's possible to restore a btrfs partition from tape backup, /if/ you
> > backed up the partition itself, not just the files on top of it.

Which is usually a quite bad idea: unless you shut down (or remount ro) the
filesystem in question, the data _will_ be corrupted, and in the case of
btrfs, this kind of corruption tends to be fatal.  You also back up all the
unused space (trim greatly recommended), and the backup process takes ages
as it needs to read everything.

An efficient block-level backup of btrfs _would_ be possible as it can
nicely enumerate blocks touched since generation X, but AFAIK no one wrote
such a program yet.  It'd be also corruption free if done in two passes:
first a racey copy, fsfreeze(), copy of just newest updates.

> > Otherwise, as you deduce, you get the files, but not the snapshot history
> > or relationship, nor the subvolumes, which will look to normal file-level
> > backup software (that is, backup software not designed with btrfs-
> > specifics like subvolumes, which if it did, would likely use btrfs send/
> > receive at least optionally) like normal directories.

If the backup software does incrementals well, this is not as bad as it
sounds.  While rsync takes half an hour just to stat() a typical small piece
spinning rust (obviously depending on # of files), that's still in the
acceptable range.  That backup software can be then be told to back every
snapshot in turn.  You still lose reflinks between unrelated subvolumes but
those tend to be quite rare -- and you can re-dedupe.

> i apprehend that i have just a file based backup.  We use EMC Networker
> (version 8.1 or 8.2), and from what i read in the net i think it does not
> support BTRFS.  So i have to reinstall, which is maybe not the worst,
> because i'm thinking about using SLES 11 SP3.
> 
> What i know now is that i can't rely on our EMC backup.
> What would you propose to backup a complete btrfs partition
> (https://btrfs.wiki.kernel.org/index.php/Incremental_Backup) ?
> We have a NAS with propable enough space, and the servers aren't used
> heavily over night.  So using one of the mentioned tools in a cronjob over
> night is possible.

> Which tool do you recommend ?

It depends on what you use subvolumes for.

While a simple file-base backup may be inadequate for the general case, for
most actual uses it works well or at least well enough.  Only if you're
doing something special, bothering with the complexity might be worth it.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U. 
⣾⠁⢰⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift
⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters
⠈⠳⣄⠀⠀⠀⠀ relevant to duties], shall be punished by death by shooting.

Re: SLES 11 SP4: can't mount btrfs

[Lentes, Bernd]

----- Am 21. Okt 2017 um 20:07 schrieb Adam Borowski kilobyte@angband.pl:

>> > Yes it's possible to restore a btrfs partition from tape backup, /if/ you
>> > backed up the partition itself, not just the files on top of it.
> 
> Which is usually a quite bad idea: unless you shut down (or remount ro) the
> filesystem in question, the data _will_ be corrupted, and in the case of
> btrfs, this kind of corruption tends to be fatal.  You also back up all the
> unused space (trim greatly recommended), and the backup process takes ages
> as it needs to read everything.
> 
> An efficient block-level backup of btrfs _would_ be possible as it can
> nicely enumerate blocks touched since generation X, but AFAIK no one wrote
> such a program yet.  It'd be also corruption free if done in two passes:
> first a racey copy, fsfreeze(), copy of just newest updates.
> 
>> > Otherwise, as you deduce, you get the files, but not the snapshot history
>> > or relationship, nor the subvolumes, which will look to normal file-level
>> > backup software (that is, backup software not designed with btrfs-
>> > specifics like subvolumes, which if it did, would likely use btrfs send/
>> > receive at least optionally) like normal directories.
> 
> If the backup software does incrementals well, this is not as bad as it
> sounds.  While rsync takes half an hour just to stat() a typical small piece
> spinning rust (obviously depending on # of files), that's still in the
> acceptable range.  That backup software can be then be told to back every
> snapshot in turn.  You still lose reflinks between unrelated subvolumes but
> those tend to be quite rare -- and you can re-dedupe.
> 
>> i apprehend that i have just a file based backup.  We use EMC Networker
>> (version 8.1 or 8.2), and from what i read in the net i think it does not
>> support BTRFS.  So i have to reinstall, which is maybe not the worst,
>> because i'm thinking about using SLES 11 SP3.
>> 
>> What i know now is that i can't rely on our EMC backup.
>> What would you propose to backup a complete btrfs partition
>> (https://btrfs.wiki.kernel.org/index.php/Incremental_Backup) ?
>> We have a NAS with propable enough space, and the servers aren't used
>> heavily over night.  So using one of the mentioned tools in a cronjob over
>> night is possible.
> 
>> Which tool do you recommend ?
> 
> It depends on what you use subvolumes for.
> 
> While a simple file-base backup may be inadequate for the general case, for
> most actual uses it works well or at least well enough.  Only if you're
> doing something special, bothering with the complexity might be worth it.
> 
> 

SLES creates a resonable number of subvolumes for e.g. /var/lib, /var/log, /tmp ...
About 15 on a normal system. My setup would be a root-Partition on btrfs, with all the subvolumes.
Here mount from a SLES 12 SP2 system:
/dev/sda1 on / type btrfs (rw,ssd,space_cache,subvolid=1011,subvol=/@/.snapshots/355/snapshot)
/dev/sda1 on /var/crash type btrfs (rw,relatime,ssd,space_cache,subvolid=264,subvol=/@/var/crash)
/dev/sda1 on /var/log type btrfs (rw,relatime,ssd,space_cache,subvolid=268,subvol=/@/var/log)
/dev/sda1 on /boot/grub2/x86_64-efi type btrfs (rw,relatime,ssd,space_cache,subvolid=259,subvol=/@/boot/grub2/x86_64-efi)
/dev/sda1 on /var/tmp type btrfs (rw,relatime,ssd,space_cache,subvolid=271,subvol=/@/var/tmp)
/dev/sda1 on /var/opt type btrfs (rw,relatime,ssd,space_cache,subvolid=269,subvol=/@/var/opt)
/dev/sda1 on /usr/local type btrfs (rw,relatime,ssd,space_cache,subvolid=263,subvol=/@/usr/local)
/dev/sda1 on /opt type btrfs (rw,relatime,ssd,space_cache,subvolid=260,subvol=/@/opt)
/dev/sda1 on /var/lib/named type btrfs (rw,relatime,ssd,space_cache,subvolid=266,subvol=/@/var/lib/named)
/dev/sda1 on /var/spool type btrfs (rw,relatime,ssd,space_cache,subvolid=270,subvol=/@/var/spool)
/dev/sda1 on /var/lib/mailman type btrfs (rw,relatime,ssd,space_cache,subvolid=265,subvol=/@/var/lib/mailman)
/dev/sda1 on /var/lib/pgsql type btrfs (rw,relatime,ssd,space_cache,subvolid=267,subvol=/@/var/lib/pgsql)
/dev/sda1 on /tmp type btrfs (rw,relatime,ssd,space_cache,subvolid=262,subvol=/@/tmp)
/dev/sda1 on /boot/grub2/i386-pc type btrfs (rw,relatime,ssd,space_cache,subvolid=258,subvol=/@/boot/grub2/i386-pc)
/dev/sda1 on /srv type btrfs (rw,relatime,ssd,space_cache,subvolid=261,subvol=/@/srv)
/dev/sda1 on /.snapshots type btrfs (rw,relatime,ssd,space_cache,subvolid=275,subvol=/@/.snapshots)

My setup would be identical.
It will be a node of a HA-cluster, no databases or s.th. else on the root-Partition. The resources are virtual machines on dedicated partitions.

What would be the appropriate backup solution from https://btrfs.wiki.kernel.org/index.php/Incremental_Backup to be able to restore the complete btrfs partition 
including all subvolumes if i have a complete corruption like now ?

Bernd
 

Helmholtz Zentrum Muenchen
Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
Ingolstaedter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen
Registergericht: Amtsgericht Muenchen HRB 6466
USt-IdNr: DE 129521671

Re: SLES 11 SP4: can't mount btrfs

[Austin S. Hemmelgarn]

On 2017-10-21 14:07, Adam Borowski wrote:
> On Sat, Oct 21, 2017 at 01:46:06PM +0200, Lentes, Bernd wrote:
>> ----- Am 21. Okt 2017 um 4:31 schrieb Duncan 1i5t5.duncan@cox.net:
>>> Lentes, Bernd posted on Fri, 20 Oct 2017 20:40:15 +0200 as excerpted:
>>>
>>>> Is it generally possible to restore a btrfs partition from a tape backup
>>>> ?
>>>> I'm just starting, and I'm asking myself. What is about the subvolumes ?
>>>> This information isn't stored in files, but in the fs ? This is not on a
>>>> file-based backup on a tape.
>>>
>>> Yes it's possible to restore a btrfs partition from tape backup, /if/ you
>>> backed up the partition itself, not just the files on top of it.
> 
> Which is usually a quite bad idea: unless you shut down (or remount ro) the
> filesystem in question, the data _will_ be corrupted, and in the case of
> btrfs, this kind of corruption tends to be fatal.  You also back up all the
> unused space (trim greatly recommended), and the backup process takes ages
> as it needs to read everything.
> 
> An efficient block-level backup of btrfs _would_ be possible as it can
> nicely enumerate blocks touched since generation X, but AFAIK no one wrote
> such a program yet.  It'd be also corruption free if done in two passes:
> first a racey copy, fsfreeze(), copy of just newest updates.
I think partimage _might_ have BTRFS support by now, and if so, that's 
likely to be the best you can get for quite some time.
> 
>>> Otherwise, as you deduce, you get the files, but not the snapshot history
>>> or relationship, nor the subvolumes, which will look to normal file-level
>>> backup software (that is, backup software not designed with btrfs-
>>> specifics like subvolumes, which if it did, would likely use btrfs send/
>>> receive at least optionally) like normal directories.
> 
> If the backup software does incrementals well, this is not as bad as it
> sounds.  While rsync takes half an hour just to stat() a typical small piece
> spinning rust (obviously depending on # of files), that's still in the
> acceptable range.  That backup software can be then be told to back every
> snapshot in turn.  You still lose reflinks between unrelated subvolumes but
> those tend to be quite rare -- and you can re-dedupe.
> 
>> i apprehend that i have just a file based backup.  We use EMC Networker
>> (version 8.1 or 8.2), and from what i read in the net i think it does not
>> support BTRFS.  So i have to reinstall, which is maybe not the worst,
>> because i'm thinking about using SLES 11 SP3.
>>
>> What i know now is that i can't rely on our EMC backup.
>> What would you propose to backup a complete btrfs partition
>> (https://btrfs.wiki.kernel.org/index.php/Incremental_Backup) ?
>> We have a NAS with propable enough space, and the servers aren't used
>> heavily over night.  So using one of the mentioned tools in a cronjob over
>> night is possible.
> 
>> Which tool do you recommend ?
> 
> It depends on what you use subvolumes for.
And this is the important part.  If you're just using them to segregate 
workloads (like I do), or exclude things from snapshots (like I used to 
do when I was using snapshots for backups), then any old backup program 
is fine as long as you know enough to replicate the subvolume layout 
when extracting (if you need the same layout that is).  I'm actually 
working on a script to automate this for file-level backups (stuff like 
Amanda, Bareos, and borgbackup), but I don't have anything ready to 
share yet.>
> While a simple file-base backup may be inadequate for the general case, for
> most actual uses it works well or at least well enough.  Only if you're
> doing something special, bothering with the complexity might be worth it.
SLES (and OpenSUSE in general) does do something special though, they 
use subvolumes and qgroups to replicate multiple independent partitions 
(which is a serious pain in the arse), and they have snapshotting with 
snapper by default as well.  On OpenSUSE at least you can dispense with 
all that crap by telling the installer to not enable snapshot support, 
not sure about SLES though.

RE: SLES 11 SP4: can't mount btrfs

[Lentes, Bernd]

> -----Original Message-----
> From: Austin S. Hemmelgarn [mailto:ahferroin7@gmail.com]
> Sent: Tuesday, October 24, 2017 1:53 PM
> To: Adam Borowski <kilobyte@angband.pl>; Lentes, Bernd
> <bernd.lentes@helmholtz-muenchen.de>
> Cc: Btrfs ML <linux-btrfs@vger.kernel.org>
> Subject: Re: SLES 11 SP4: can't mount btrfs
>
> I think partimage _might_ have BTRFS support by now, and if so, that's
> likely to be the best you can get for quite some time.

Unfortunately not: http://www.partimage.org/Supported-Filesystems/

> > It depends on what you use subvolumes for.
> And this is the important part.  If you're just using them to segregate
> workloads (like I do), or exclude things from snapshots (like I used to do
> when I was using snapshots for backups), then any old backup program is
> fine as long as you know enough to replicate the subvolume layout when
> extracting (if you need the same layout that is).  I'm actually working on 
> a
> script to automate this for file-level backups (stuff like Amanda, Bareos,
> and borgbackup), but I don't have anything ready to share yet.>

There seems to be no backup solution which supports BTRFS in a way that I 
can just restore the complete partition with all subvolumes, snapshots ? 
That's bad. A fs can also get corrupt in certain circumstances.
I'd like to have a solution which offers me the possibility to restore a 
root partition in a reasonable time (some hours maximum), completely. Not 
doing many stuff before/afterwards. It seems that's not possible withBTRFS.

And Btrfs check is still limited in what it can do.


Bernd
 

Helmholtz Zentrum Muenchen
Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
Ingolstaedter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen
Registergericht: Amtsgericht Muenchen HRB 6466
USt-IdNr: DE 129521671

Re: SLES 11 SP4: can't mount btrfs

[Austin S. Hemmelgarn]

On 2017-10-24 09:28, Lentes, Bernd wrote:
> 
>> -----Original Message-----
>> From: Austin S. Hemmelgarn [mailto:ahferroin7@gmail.com]
>> Sent: Tuesday, October 24, 2017 1:53 PM
>> To: Adam Borowski <kilobyte@angband.pl>; Lentes, Bernd
>> <bernd.lentes@helmholtz-muenchen.de>
>> Cc: Btrfs ML <linux-btrfs@vger.kernel.org>
>> Subject: Re: SLES 11 SP4: can't mount btrfs
>>
>> I think partimage _might_ have BTRFS support by now, and if so, that's
>> likely to be the best you can get for quite some time.
> 
> Unfortunately not: http://www.partimage.org/Supported-Filesystems/
> 
>>> It depends on what you use subvolumes for.
>> And this is the important part.  If you're just using them to segregate
>> workloads (like I do), or exclude things from snapshots (like I used to do
>> when I was using snapshots for backups), then any old backup program is
>> fine as long as you know enough to replicate the subvolume layout when
>> extracting (if you need the same layout that is).  I'm actually working on
>> a
>> script to automate this for file-level backups (stuff like Amanda, Bareos,
>> and borgbackup), but I don't have anything ready to share yet.>
> 
> There seems to be no backup solution which supports BTRFS in a way that I
> can just restore the complete partition with all subvolumes, snapshots ?
> That's bad. A fs can also get corrupt in certain circumstances.
> I'd like to have a solution which offers me the possibility to restore a
> root partition in a reasonable time (some hours maximum), completely. Not
> doing many stuff before/afterwards. It seems that's not possible withBTRFS.
A short-term alternative, if you've got a full backup of what SLES 
mounts as /, is to run a regular install, boot the system, and then 
extract the backup on top of /.  It's not perfect, but it should work 
well enough.

As mentioned, I'm working on a script to handle this for tools like 
Amanda and Bareos.  I plan to send a message out on the list when that's 
sufficiently working that I think it's safely usable, I can make sure 
you're on CC for that message as well if you like.  I hoped to have 
something later this week, but things are busier than expected at work 
this week, so it might be a while.
> 
> And Btrfs check is still limited in what it can do.

RE: SLES 11 SP4: can't mount btrfs

[Lentes, Bernd]

> -----Original Message-----
> From: linux-btrfs-owner@vger.kernel.org 
> [mailto:linux-btrfs-owner@vger.kernel.org] On Behalf Of Austin S. 
> Hemmelgarn
> Sent: Tuesday, October 24, 2017 4:05 PM
> To: Lentes, Bernd <bernd.lentes@helmholtz-muenchen.de>; Btrfs ML 
> <linux-btrfs@vger.kernel.org>
> Subject: Re: SLES 11 SP4: can't mount btrfs
>
> A short-term alternative, if you've got a full backup of what SLES
> mounts as /, is to run a regular install, boot the system, and then
> extract the backup on top of /.  It's not perfect, but it should work
> well enough.

That's what I'm currently trying. I will keep you informed.

> As mentioned, I'm working on a script to handle this for tools like
> Amanda and Bareos.  I plan to send a message out on the list when that's
> sufficiently working that I think it's safely usable, I can make sure
> you're on CC for that message as well if you like.  I hoped to have
> something later this week, but things are busier than expected at work
> this week, so it might be a while.

Please put me on cc. That would be great. Thanks.


Bernd
 

Helmholtz Zentrum Muenchen
Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
Ingolstaedter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen
Registergericht: Amtsgericht Muenchen HRB 6466
USt-IdNr: DE 129521671

RE: SLES 11 SP4: can't mount btrfs

[Lentes, Bernd]

> -----Original Message-----
> From: linux-btrfs-owner@vger.kernel.org 
> [mailto:linux-btrfs-owner@vger.kernel.org] On Behalf Of Lentes, Bernd
> Sent: Tuesday, October 24, 2017 6:44 PM
> To: Btrfs ML <linux-btrfs@vger.kernel.org>
> Subject: RE: SLES 11 SP4: can't mount btrfs
>
>
> >
> > A short-term alternative, if you've got a full backup of what SLES
> > mounts as /, is to run a regular install, boot the system, and then
> > extract the backup on top of /.  It's not perfect, but it should work
> > well enough.
>
> That's what I'm currently trying. I will keep you informed.
>

I was able to restore the root fs. I formatted the / partition with Btrfs 
again and could restore the files from a backup.
Everything seems to be there, I can mount the Btrfs manually.
But booting does not work. My Btrfs resides on a logical volume. I changed 
/boot/grub/menu.lst and /etc/fstab to point to the lv. Before it was 
pointing to a UUID.
But booting my SLES complains that it does not find the root fs. screenshot: 
https://hmgubox.helmholtz-muenchen.de/f/2d6b374e8a8b40569d4f/?dl=1

I can manually mount from the booted SLES. So everything (Btrfs, lvm) seems 
to be available. I added in menu.lst and fstab the path to the device node 
(/dev/vg1/lv_root), which works on other systems the same way, the only 
difference is there I have ext3.
But SLES finds from where I don't know a UUID (see screenshot). This UUID is 
commented out in fstab and replaced by /dev/vg1/lv_root. Using 
/dev/vg1/lv_root I can manually mount my Btrfs without any problem.

Where does my SLES find that UUID ? It is not available unter 
/dev/disk/by-uuid. Can I change that value ?

Thanks for any help.


Bernd
 

Helmholtz Zentrum Muenchen
Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
Ingolstaedter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen
Registergericht: Amtsgericht Muenchen HRB 6466
USt-IdNr: DE 129521671

RE: SLES 11 SP4: can't mount btrfs

[Peter Grandi]

> I formatted the / partition with Btrfs again and could restore
> the files from a backup.  Everything seems to be there, I can
> mount the Btrfs manually. [ ... ] But SLES finds from where I
> don't know a UUID (see screenshot). This UUID is commented out
> in fstab and replaced by /dev/vg1/lv_root. Using
> /dev/vg1/lv_root I can manually mount my Btrfs without any
> problem. Where does my SLES find that UUID ?

This sounds like a SLES issue, rather than a Btrfs one.

But it could simply be that you have forgotten to refresh the
'initramfs' with 'mkinitrd' after modifying the '/etc/fstab'.

RE: SLES 11 SP4: can't mount btrfs

[Lentes, Bernd]

> -----Original Message-----
> From: linux-btrfs-owner@vger.kernel.org
[mailto:linux-btrfs-owner@vger.kernel.org] On Behalf Of Peter Grandi
> Sent: Thursday, October 26, 2017 2:55 PM
> To: Linux fs Btrfs <linux-btrfs@vger.kernel.org>
> Subject: RE: SLES 11 SP4: can't mount btrfs
> 
> > I formatted the / partition with Btrfs again and could restore
> > the files from a backup.  Everything seems to be there, I can
> > mount the Btrfs manually. [ ... ] But SLES finds from where I
> > don't know a UUID (see screenshot). This UUID is commented out
> > in fstab and replaced by /dev/vg1/lv_root. Using
> > /dev/vg1/lv_root I can manually mount my Btrfs without any
> > problem. Where does my SLES find that UUID ?
> 
> This sounds like a SLES issue, rather than a Btrfs one.
> 
> But it could simply be that you have forgotten to refresh the
> 'initramfs' with 'mkinitrd' after modifying the '/etc/fstab'.

I finally managed it. I'm pretty sure having changed /boot/grub/menu.lst,
but somehow changes got lost/weren't saved ?
After entering the new UUID from my Btrfs partition system boots.

Sorry for PM Peter.


Bernd
 

Helmholtz Zentrum Muenchen
Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
Ingolstaedter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen
Registergericht: Amtsgericht Muenchen HRB 6466
USt-IdNr: DE 129521671

RE: SLES 11 SP4: can't mount btrfs

[Peter Grandi]

>> But it could simply be that you have forgotten to refresh the
>> 'initramfs' with 'mkinitrd' after modifying the '/etc/fstab'.

> I finally managed it. I'm pretty sure having changed
> /boot/grub/menu.lst, but somehow changes got lost/weren't
> saved ?

So the next thing to check would indeed have been that the GRUB2
script had been updated, which you can do with 'grub2-mkconfig'.
Also double check that in '/etc/sysconfig/bootloader' there is a
line 'LOADER_TYPE="grub"' instead of "none".

The system config tools will update the 'initramfs' and the
'menu.lst' automatically only if you make system config changes
only using them, but you changed the UUID of '/' "manually", and
this perhaps put the GRUB2 config and the system state out of
sync.

> After entering the new UUID from my Btrfs partition system
> boots.

Alternatively you could have used 'btrfstune -U ... ...' to
change the UUID of the newly created '/' volume to the old one.

Re: SLES 11 SP4: can't mount btrfs

[Andrei Borzenkov]

26.10.2017 15:18, Lentes, Bernd пишет:
> 
>> -----Original Message-----
>> From: linux-btrfs-owner@vger.kernel.org 
>> [mailto:linux-btrfs-owner@vger.kernel.org] On Behalf Of Lentes, Bernd
>> Sent: Tuesday, October 24, 2017 6:44 PM
>> To: Btrfs ML <linux-btrfs@vger.kernel.org>
>> Subject: RE: SLES 11 SP4: can't mount btrfs
>>
>>
>>>
>>> A short-term alternative, if you've got a full backup of what SLES
>>> mounts as /, is to run a regular install, boot the system, and then
>>> extract the backup on top of /.  It's not perfect, but it should work
>>> well enough.
>>
>> That's what I'm currently trying. I will keep you informed.
>>
> 
> I was able to restore the root fs. I formatted the / partition with Btrfs 
> again and could restore the files from a backup.
> Everything seems to be there, I can mount the Btrfs manually.
> But booting does not work. My Btrfs resides on a logical volume. I changed 
> /boot/grub/menu.lst and /etc/fstab to point to the lv. Before it was 
> pointing to a UUID.
> But booting my SLES complains that it does not find the root fs. screenshot: 
> https://hmgubox.helmholtz-muenchen.de/f/2d6b374e8a8b40569d4f/?dl=1
> 
> I can manually mount from the booted SLES. So everything (Btrfs, lvm) seems 
> to be available. I added in menu.lst and fstab the path to the device node 
> (/dev/vg1/lv_root), which works on other systems the same way, the only 
> difference is there I have ext3.
> But SLES finds from where I don't know a UUID (see screenshot). This UUID is 
> commented out in fstab and replaced by /dev/vg1/lv_root. Using 
> /dev/vg1/lv_root I can manually mount my Btrfs without any problem.
> 
> Where does my SLES find that UUID ? It is not available unter 
> /dev/disk/by-uuid. Can I change that value ?
> 

root device information is stored in initrd, you need to rebuild it.
Just run mkinitrd after you boot system.

RE: SLES 11 SP4: can't mount btrfs

[Lentes, Bernd]

> -----Original Message-----
> From: Andrei Borzenkov [mailto:arvidjaar@gmail.com]
> Sent: Thursday, October 26, 2017 6:51 PM
> To: Lentes, Bernd <bernd.lentes@helmholtz-muenchen.de>; Btrfs ML 
> <linux-btrfs@vger.kernel.org>
> Subject: Re: SLES 11 SP4: can't mount btrfs

>
> root device information is stored in initrd, you need to rebuild it.
> Just run mkinitrd after you boot system.

I can't confirm that. Just moved an old SLES 10 SP4 from one host to the 
other. Just changed menu.lst (GRUB) and fstab, system is booting. No need to 
rebuild initrd.
But maybe just because it's an old system.


Bernd
 

Helmholtz Zentrum Muenchen
Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
Ingolstaedter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen
Registergericht: Amtsgericht Muenchen HRB 6466
USt-IdNr: DE 129521671

Re: SLES 11 SP4: can't mount btrfs

[Andrei Borzenkov]

On Tue, Oct 24, 2017 at 2:53 PM, Austin S. Hemmelgarn
<ahferroin7@gmail.com> wrote:
>
> SLES (and OpenSUSE in general) does do something special though, they use
> subvolumes and qgroups to replicate multiple independent partitions (which
> is a serious pain in the arse), and they have snapshotting with snapper by
> default as well.  On OpenSUSE at least you can dispense with all that crap
> by telling the installer to not enable snapshot support, not sure about SLES
> though.

SUSE is using so many subvolumes because
a) it wants to use snapshot of operating system to enable rollback
b) data that needs to be part of snapshot includes RPM database
c) RPM database is located on /var

So they were forced to make /var part of root subvolume and explicitly
exclude everything below /var by making it separate subvolumes.

Fortunately it is going to change now with both RH and SUSE moving RPM
database under /usr. Which leaves you basically with / and /var as
default subvolumes.

Re: SLES 11 SP4: can't mount btrfs

[Austin S. Hemmelgarn]

On 2017-10-24 10:12, Andrei Borzenkov wrote:
> On Tue, Oct 24, 2017 at 2:53 PM, Austin S. Hemmelgarn
> <ahferroin7@gmail.com> wrote:
>>
>> SLES (and OpenSUSE in general) does do something special though, they use
>> subvolumes and qgroups to replicate multiple independent partitions (which
>> is a serious pain in the arse), and they have snapshotting with snapper by
>> default as well.  On OpenSUSE at least you can dispense with all that crap
>> by telling the installer to not enable snapshot support, not sure about SLES
>> though.
> 
> SUSE is using so many subvolumes because
> a) it wants to use snapshot of operating system to enable rollback
> b) data that needs to be part of snapshot includes RPM database
> c) RPM database is located on /var
> 
> So they were forced to make /var part of root subvolume and explicitly
> exclude everything below /var by making it separate subvolumes.
> 
> Fortunately it is going to change now with both RH and SUSE moving RPM
> database under /usr. Which leaves you basically with / and /var as
> default subvolumes.
> 
And /tmp, and /opt, and /usr/local, etc.  With /var as one subvolume, I 
still count at least 8.

That said, the issue I have with it is not as much the number, as the 
choice of layout (the whole /@ crap is ridiculous), and the fact that 
qgroups are enabled by default and not very well documented anywhere 
that I could find (seriously, this needs to be better documented, it 
took me an hour despite my background with BTRFS and as a system 
administrator to figure out why I couldn't fill the disk completely 
anywhere to wipe free space with zeroes so I could compact the disk 
image for the VM I was using).

Re: SLES 11 SP4: can't mount btrfs

[Duncan]

Chris Murphy posted on Thu, 19 Oct 2017 21:04:26 +0100 as excerpted:

> On Thu, Oct 19, 2017 at 6:43 PM, Lentes, Bernd
> <bernd.lentes@helmholtz-muenchen.de> wrote:
>> Hi,
>>
>> this is the continuation of a thread i started on a SLES forum
>> (https://forums.suse.com/showthread.php?10109-lv-with-btrfs-corrupt-
some-tips-please),
>> but i think this is the more appropriate place.
> 
> Maybe, but as this is SLES, you're effectively paying for support, and
> it's actually better to open a support instance, in my opinion.

This is what I'd recommend as well.

That 3.0.x kernel is well out of the range this list tends to support, 
given that it's a forward-focused development list, not a stability-
focused enterprise release support list.  We generally go back a couple 
release series each in the mainline current and LTS release series, which 
means 4.13 and 4.12 on current, and 4.9 and 4.4 on LTS, but even 4.4 is 
getting pretty long in the tooth for this list, so it's fortunate that 
the coming 4.14 is going to be an LTS as well.

While your knoppix had kernel 4.12.x which is list-reasonable for runtime, 
where the kernel code is primary, once something's going wrong and you 
can't mount, it's the userspace code that is responsible for check/rescue/
restore, and there your knoppix was a bit behind at 4.7.x.

So your choices are to go really current and build a 4.13.x btrfs-progs 
to try, or to go with the SLES support you're paying for anyway, in which 
case you run what they say they'll support.  Given that you were running 
that old code (plus backports we don't track as we're focused on mainline 
and forward development) already, and a 3.0 kernel really is scary-
ancient in btrfs terms, they really are best positioned to support it, 
and given that you're presumably paying good money for that support 
already, you might as well use what you're paying for.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman