btrfstune -u makes filesystem unmountable

btrfstune -u makes filesystem unmountable

[Richard C]

Hi,

I'm writing a backup script that images a btrfs using btrfs-image,
then restores to a file on a loop device. Since I had trouble mounting
the original and copied btrfs filesystems with the same UUID on the
same machine, I decided to try btrfstune -fu. However, this appears to
corrupt the copied filesystem altogether making fsck and mount fail.
Details below.
Is this a bug?

$ uname -a
Linux adventure 3.16.0-67-generic #87~14.04.1-Ubuntu SMP Fri Mar 11
00:26:02 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
$ btrfs --version
btrfs-progs v4.4

$ btrfstune -fu /dev/loop2
Current fsid: 36012b08-1e33-4d3c-ac23-5ccffd3295cd
New fsid: 8f70d0af-8ffa-4c82-a817-941e6abfaf9a
Set superblock flag CHANGING_FSID
Change fsid in extents
Change fsid on devices
Clear superblock flag CHANGING_FSID
Fsid change finished

$ btrfs check /dev/loop2
fsid mismatch, want=36012b08-1e33-4d3c-ac23-5ccffd3295cd,
have=8f70d0af-8ffa-4c82-a817-941e6abfaf9a
Couldn't read chunk root
Couldn't open file system
$ echo $?
251

$ mount /dev/loop2 /mnt
 mount: wrong fs type, bad option, bad superblock on /dev/loop2,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so
$ echo $?
32

Re: btrfstune -u makes filesystem unmountable

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1710 bytes --]

On Sun, Apr 10, 2016 at 03:47:44PM +0100, Richard C wrote:
> Hi,
> 
> I'm writing a backup script that images a btrfs using btrfs-image,

   You are aware that btrfs-image copies only the metadata? The data
is _not_ a part of the image, so it's a fairly poor implementation of
a backup process.

   Hugo.

> then restores to a file on a loop device. Since I had trouble mounting
> the original and copied btrfs filesystems with the same UUID on the
> same machine, I decided to try btrfstune -fu. However, this appears to
> corrupt the copied filesystem altogether making fsck and mount fail.
> Details below.
> Is this a bug?
> 
> $ uname -a
> Linux adventure 3.16.0-67-generic #87~14.04.1-Ubuntu SMP Fri Mar 11
> 00:26:02 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
> $ btrfs --version
> btrfs-progs v4.4
> 
> $ btrfstune -fu /dev/loop2
> Current fsid: 36012b08-1e33-4d3c-ac23-5ccffd3295cd
> New fsid: 8f70d0af-8ffa-4c82-a817-941e6abfaf9a
> Set superblock flag CHANGING_FSID
> Change fsid in extents
> Change fsid on devices
> Clear superblock flag CHANGING_FSID
> Fsid change finished
> 
> $ btrfs check /dev/loop2
> fsid mismatch, want=36012b08-1e33-4d3c-ac23-5ccffd3295cd,
> have=8f70d0af-8ffa-4c82-a817-941e6abfaf9a
> Couldn't read chunk root
> Couldn't open file system
> $ echo $?
> 251
> 
> $ mount /dev/loop2 /mnt
>  mount: wrong fs type, bad option, bad superblock on /dev/loop2,
>        missing codepage or helper program, or other error
>        In some cases useful info is found in syslog - try
>        dmesg | tail  or so
> $ echo $?
> 32

-- 
Hugo Mills             | There's many a slip 'twixt wicket-keeper and gully.
hugo@... carfax.org.uk |
http://carfax.org.uk/  |
PGP: E2AB1DE4          |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: btrfstune -u makes filesystem unmountable

[Duncan]

Richard C posted on Sun, 10 Apr 2016 15:47:44 +0100 as excerpted:

> Hi,
> 
> I'm writing a backup script that images a btrfs using btrfs-image, then
> restores to a file on a loop device. Since I had trouble mounting the
> original and copied btrfs filesystems with the same UUID on the same
> machine, I decided to try btrfstune -fu. However, this appears to
> corrupt the copied filesystem altogether making fsck and mount fail.
> Details below.

Of course as Hugo mentions, btrfs-image (which is primarily a debugging 
tool simply images the metadata, not the data.  So it can't be used for 
backups, as you're doing it.

The closest thing to that would be creating a new btrfs, then using btrfs 
send on snapshots taken on the old filesystem, sent to btrfs receive on 
the new filesystem, creating a copy of the sent snapshot on the new 
filesystem.  (Unfortunately, for those using multiple subvolumes, that 
means multiple send/receives, as the recursive-send feature isn't yet 
implemented and thus doesn't work.)

> Is this a bug?
> 
> $ uname -a
> Linux adventure 3.16.0-67-generic #87~14.04.1-Ubuntu SMP Fri
> Mar 11 00:26:02 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
> $ btrfs --version
> btrfs-progs v4.4

Of course you know that a 3.16 kernel isn't well supported on this list, 
right?  Btrfs is still stabilizing, and as such, that's simply too old to 
properly support on-list.

On-list kernel recommendations fall into two tracks, mainline LTS, and 
mainline current.  On the current kernel track, we recommend keeping to 
the latest couple kernel releases, which are supported with current 
kernel track stable releases.  With 4.5 the latest, that means 4.4 or 4.5 
series.

On the LTS (long-term-support) track, until recently it was again the 
latest two kernel series, but of the mainstream kernel LTS series.  4.4 
is the latest LTS series and 4.1 was the previous one.  However, as btrfs 
has continued to stabilize and mature, the previous one to that, 3.18, 
ended up reasonably stable and problem free, so while we still recommend 
the lastest two LTS series, we know some people will prefer to stick with 
3.18 awhile longer, and given that it actually has been pretty good, it's 
still reasonably acceptable as well... as long as you're not trying to do 
btrfs raid56, anyway, as it's still new enough following the current 
kernel track is recommended.

With 3.18 the oldest reasonably well supported LTS series, and 3.16 being 
previous to that, it's well out of the recommended support range.  And 
3.16 wasn't even an LTS kernel series; the one before 3.18 was 3.14, 
which was a VERY long time ago in btrfs development terms and is thus out 
of the recommended range even tho it is an LTS kernel.

Of course some distros choose to support btrfs only older kernels and we 
recognize that.  However, we focus on mainline on this list, and aren't 
in a position to track what patches may or may not have been backported 
to base-kernels that old, which means we really can't support them very 
well.  If you're relying on a distro's btrfs support on that old a 
kernel, that's really where you should be looking for support, not here, 
as we're simply not equipped to provide it.  That doesn't mean we won't 
do our best, but it does mean that the best support we're likely going to 
be able to provide in response to any reported problem is likely to be 
recommending that you upgrade to a newer kernel and see if the problem 
still exists, reporting the output, etc, there, if it does.

OTOH, you're doing great on the btrfs-tools userspace, where you're using 
4.4. =:^)  The rule of thumb there is to make sure you're using a 
userspace version at least comparable to your kernel version, which if 
you're following kernel recommendations, will ensure that you don't get 
/too/ far behind with userspace as well, since the version numbers are 
synced and a userspace release of a particular series tends to come a 
week or so after the corresponding kernel series .0 release.  So 4.4 is 
great there.  If your kernel was only as current as your userspace, you'd 
be great. =:^)

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