Re: Problem with BTRFS

[Rafael Jesús Alcántara Pérez]

Hi:

I've installed the package from your link and it has fixed the issue ;)

$ sudo btrfs rescue fix-device-size /dev/sdc1
Fixed device size for devid 3, old size: 1999843081728 new size:
1999843078144
Fixed device size for devid 5, old size: 1999843081728 new size:
1999843078144
Fixed device size for devid 4, old size: 1999843081728 new size:
1999843078144
Fixed super total bytes, old size: 601020864 new size: 6010266652672
Fixed unaligned/mismatched total_bytes for super block and device items

Thank you very much.

El 14/09/18 a las 22:24, Nicholas D Steeves escribió:
> Hi,
> 
> On Fri, Sep 14, 2018 at 10:13:06PM +0200, Rafael Jesús Alcántara Pérez wrote:
>> Hi,
>>
>> It seems that btrfs-progs_4.17-1 from Sid, includes that feature (at
>> least, it says so in the manual page). I don't know if I can install it
>> on Stretch but I'll try.
>>
>> Greets and thank you very much to both of you ;)
>> Rafael J. Alcántara Pérez.
> 
> Please do not install btrfs-progs from sid on stretch, it's likely to
> break your system.  If you can't wait, here is a link to what I
> uploaded.  It includes both the source and the binary packages (see
> gpg signed changes file, and please take care to verify the binaries
> weren't tampered with):
> 
> https://drive.google.com/file/d/1WflwBEn-QN_btrKPiefz7Kxz58VT8kIQ/view?usp=sharing
> 
> Of course, this package is unofficial.  The official one will soon
> become available through the regular channels.
> 
> For best results, set up a local file:// apt repository so that apt
> update && apt upgrade will work properly.  Official bpo will
> automatically overwrite these, in any case.
> 
> Cheers,
> Nicholas
> 


-- 

Re: Problem with BTRFS

[Nicholas D Steeves]

Hi,

On Fri, Sep 14, 2018 at 10:13:06PM +0200, Rafael Jesús Alcántara Pérez wrote:
> Hi,
> 
> It seems that btrfs-progs_4.17-1 from Sid, includes that feature (at
> least, it says so in the manual page). I don't know if I can install it
> on Stretch but I'll try.
> 
> Greets and thank you very much to both of you ;)
> Rafael J. Alcántara Pérez.

Please do not install btrfs-progs from sid on stretch, it's likely to
break your system.  If you can't wait, here is a link to what I
uploaded.  It includes both the source and the binary packages (see
gpg signed changes file, and please take care to verify the binaries
weren't tampered with):

https://drive.google.com/file/d/1WflwBEn-QN_btrKPiefz7Kxz58VT8kIQ/view?usp=sharing

Of course, this package is unofficial.  The official one will soon
become available through the regular channels.

For best results, set up a local file:// apt repository so that apt
update && apt upgrade will work properly.  Official bpo will
automatically overwrite these, in any case.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Re: Problem with BTRFS

[Rafael Jesús Alcántara Pérez]

Hi,

It seems that btrfs-progs_4.17-1 from Sid, includes that feature (at
least, it says so in the manual page). I don't know if I can install it
on Stretch but I'll try.

Greets and thank you very much to both of you ;)
Rafael J. Alcántara Pérez.

El 14/09/18 a las 20:18, Nicholas D Steeves escribió:
> Hi,
> 
> On Fri, Sep 14, 2018 at 10:46:12PM +0500, Roman Mamedov wrote:
>> On Fri, 14 Sep 2018 19:27:04 +0200
>> Rafael Jesús Alcántara Pérez  wrote:
>>
>>> BTRFS info (device sdc1): use lzo compression, level 0
>>> BTRFS warning (device sdc1): 'recovery' is deprecated, use
>>> 'usebackuproot' instead
>>> BTRFS info (device sdc1): trying to use backup root at mount time
>>> BTRFS info (device sdc1): disk space caching is enabled
>>> BTRFS info (device sdc1): has skinny extents
>>> BTRFS error (device sdc1): super_total_bytes 601020864 mismatch with
>>> fs_devices total_rw_bytes 601023424
>>
>> There is a recent feature added to "btrfs rescue" to fix this kind of
>> condition: https://patchwork.kernel.org/patch/10011399/
>>
>> You need a recent version of the Btrfs tools for it, not sure which, I see
>> that it's not in version 4.13 but is present in 4.17.
> 
> btrfs-progs_4.17-1~bpo9+1_amd64.changes is waiting to pass through NEW
> (due to the new library packages in the backport).  It will take
> between 24h and several weeks to pass to stretch-backports.  The
> variability in expected delivery is because a Debian FTP Master will
> need to manually ACK the changes.
> 
> If 4.17.1 is required, please 'reportbug btrfs-progs' and take care to
> set the "found" version to 4.17-1, plus provide a citation for why
> 4.17.1 is required--without this justification the bug severity could
> be downgraded to wishlist.  This hypothetical bug would be for the
> "unstable" suite (packages migrate to testing after a period of
> testing, and then become eligible for backporting).
> 
> Take care!
> Nicholas
> 


-- 

Re: Problem with BTRFS

[Nicholas D Steeves]

Hi,

On Fri, Sep 14, 2018 at 10:46:12PM +0500, Roman Mamedov wrote:
> On Fri, 14 Sep 2018 19:27:04 +0200
> Rafael Jesús Alcántara Pérez  wrote:
> 
> > BTRFS info (device sdc1): use lzo compression, level 0
> > BTRFS warning (device sdc1): 'recovery' is deprecated, use
> > 'usebackuproot' instead
> > BTRFS info (device sdc1): trying to use backup root at mount time
> > BTRFS info (device sdc1): disk space caching is enabled
> > BTRFS info (device sdc1): has skinny extents
> > BTRFS error (device sdc1): super_total_bytes 601020864 mismatch with
> > fs_devices total_rw_bytes 601023424
> 
> There is a recent feature added to "btrfs rescue" to fix this kind of
> condition: https://patchwork.kernel.org/patch/10011399/
> 
> You need a recent version of the Btrfs tools for it, not sure which, I see
> that it's not in version 4.13 but is present in 4.17.

btrfs-progs_4.17-1~bpo9+1_amd64.changes is waiting to pass through NEW
(due to the new library packages in the backport).  It will take
between 24h and several weeks to pass to stretch-backports.  The
variability in expected delivery is because a Debian FTP Master will
need to manually ACK the changes.

If 4.17.1 is required, please 'reportbug btrfs-progs' and take care to
set the "found" version to 4.17-1, plus provide a citation for why
4.17.1 is required--without this justification the bug severity could
be downgraded to wishlist.  This hypothetical bug would be for the
"unstable" suite (packages migrate to testing after a period of
testing, and then become eligible for backporting).

Take care!
Nicholas


signature.asc
Description: PGP signature

Re: Problem with BTRFS

[Roman Mamedov]

On Fri, 14 Sep 2018 19:27:04 +0200
Rafael Jesús Alcántara Pérez  wrote:

> BTRFS info (device sdc1): use lzo compression, level 0
> BTRFS warning (device sdc1): 'recovery' is deprecated, use
> 'usebackuproot' instead
> BTRFS info (device sdc1): trying to use backup root at mount time
> BTRFS info (device sdc1): disk space caching is enabled
> BTRFS info (device sdc1): has skinny extents
> BTRFS error (device sdc1): super_total_bytes 601020864 mismatch with
> fs_devices total_rw_bytes 601023424

There is a recent feature added to "btrfs rescue" to fix this kind of
condition: https://patchwork.kernel.org/patch/10011399/

You need a recent version of the Btrfs tools for it, not sure which, I see
that it's not in version 4.13 but is present in 4.17.

-- 
With respect,
Roman

Problem with BTRFS

[Rafael Jesús Alcántara Pérez]

Hi:

After a power outage, my server refuses to mount a BTRFS file system.

This is the result of trying to mount with options recovery,ro:

BTRFS info (device sdc1): use lzo compression, level 0
BTRFS warning (device sdc1): 'recovery' is deprecated, use
'usebackuproot' instead
BTRFS info (device sdc1): trying to use backup root at mount time
BTRFS info (device sdc1): disk space caching is enabled
BTRFS info (device sdc1): has skinny extents
BTRFS error (device sdc1): super_total_bytes 601020864 mismatch with
fs_devices total_rw_bytes 601023424
BTRFS error (device sdc1): failed to read chunk tree: -22
BTRFS error (device sdc1): open_ctree failed

And this is the initial output of a "btrfs check --readonly":

  https://pastebin.com/6gs7hJTG

I'm planning to do a "btrfs recover fix-device-size" but I don't know if
it can be dangerous or if it's better to do a "btrfs check --repair" before.

Any recommendation?

Greets and thanks in advance.
Rafael J. Alcántara Pérez.
-- 

Re: Problem with BTRFS

[Rafael Jesús Alcántara Pérez]

Hi again:

Sorry, I missed some details :)

$ uname -a
Linux gemini 4.17.0-0.bpo.3-amd64 #1 SMP Debian 4.17.17-1~bpo9+1
(2018-08-27) x86_64 GNU/Linux

$ btrfs --version
btrfs-progs v4.13.3

$ sudo btrfs fi show
Label: '/srv/dedalo'  uuid: d1071744-ac3b-4926-bb43-27091ea73c05
Total devices 4 FS bytes used 2.57TiB
devid3 size 1.82TiB used 1.80TiB path /dev/sdd1
devid4 size 1.82TiB used 1.81TiB path /dev/sdc1
devid5 size 1.82TiB used 1.81TiB path /dev/sdb1
devid6 size 10.00GiB used 573.94MiB path /dev/loop0

I can't include "btrfs fi df" because I can't mount the file system.

I've attached the dmesg output to the message.

Greets and thanks again.
Rafael J. Alcántara Pérez.

El 14/09/18 a las 19:27, Rafael Jesús Alcántara Pérez escribió:
> Hi:
> 
> After a power outage, my server refuses to mount a BTRFS file system.
> 
> This is the result of trying to mount with options recovery,ro:
> 
> BTRFS info (device sdc1): use lzo compression, level 0
> BTRFS warning (device sdc1): 'recovery' is deprecated, use
> 'usebackuproot' instead
> BTRFS info (device sdc1): trying to use backup root at mount time
> BTRFS info (device sdc1): disk space caching is enabled
> BTRFS info (device sdc1): has skinny extents
> BTRFS error (device sdc1): super_total_bytes 601020864 mismatch with
> fs_devices total_rw_bytes 601023424
> BTRFS error (device sdc1): failed to read chunk tree: -22
> BTRFS error (device sdc1): open_ctree failed
> 
> And this is the initial output of a "btrfs check --readonly":
> 
>   https://pastebin.com/6gs7hJTG
> 
> I'm planning to do a "btrfs recover fix-device-size" but I don't know if
> it can be dangerous or if it's better to do a "btrfs check --repair" before.
> 
> Any recommendation?
> 
> Greets and thanks in advance.
> Rafael J. Alcántara Pérez.
> 


-- 
[0.00] Linux version 4.17.0-0.bpo.3-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Debian 4.17.17-1~bpo9+1 (2018-08-27)
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.17.0-0.bpo.3-amd64 root=UUID=e51e49de-ad23-436d-bb84-a50bb8ec8c94 ro quiet vsyscall=emulate consoleblank=0
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Enabled xstate features 0x3, context size is 576 bytes, using 'standard' format.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009] usable
[0.00] BIOS-e820: [mem 0x0010-0xbfb4] usable
[0.00] BIOS-e820: [mem 0xbfb5-0xbfb65fff] reserved
[0.00] BIOS-e820: [mem 0xbfb66000-0xbfb85bff] ACPI data
[0.00] BIOS-e820: [mem 0xbfb85c00-0xbfff] reserved
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfe00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00073fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.5 present.
[0.00] DMI: Dell Inc. PowerEdge 2900/0NX642, BIOS 2.7.0 10/30/2010
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x74 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-C write-protect
[0.00]   D-EBFFF uncachable
[0.00]   EC000-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 00 mask 3F8000 write-back
[0.00]   1 base 008000 mask 3FC000 write-back
[0.00]   2 base 01 mask 3F write-back
[0.00]   3 base 02 mask 3E write-back
[0.00]   4 base 04 mask 3C write-back
[0.00]   5 base 00BFC0 mask 3FFFC0 uncachable
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.00] e820: update [mem 0xbfc0-0x] usable ==> reserved
[0.00] e820: last_pfn = 0xbfb50 max_arch_pfn = 0x4
[0.00] found SMP MP-table at [mem 0x000fe710-0x000fe71f] mapped at [(ptrval)]
[0.00] Base memory trampoline at [(ptrval)] 99000 size 24576
[0.00] BRK [0x405e3f000, 0x405e3] PGTABLE
[0.00] BRK [0x405e4, 0x405e40fff] PGTABLE
[0.00] BRK [0x405e41000, 0x405e41fff] PGTABLE
[0.00] BRK [0x405e42000, 0x405e42fff] PGTABLE
[0.00] BRK [0x405e43000, 0x405e43fff] PGTABLE
[0.00] BRK [0x405e44000, 0x405e44fff] PGTABLE
[

RE: Problem with btrfs snapshots

[Дмитрий Нечаев]

Part of script:

btrfs filesystem sync 
cp -pR --reflink 
btrfs filesystem sync 

So if another copy or two of script is starting in the moment, then first 
snapshot is making - then we receive ENOSPC.

-Original Message-
From: Austin S. Hemmelgarn [mailto:ahferro...@gmail.com] 
Sent: Thursday, November 03, 2016 6:07 PM
To: Peter Becker; Дмитрий Нечаев; linux-btrfs
Subject: Re: Problem with btrfs snapshots

On 2016-11-03 10:21, Peter Becker wrote:
> (copy for mainlinglist)
>
> 2016-11-03 15:16 GMT+01:00 Дмитрий Нечаев <d.nech...@sigma-it.ru>:
> Yes. We tried "sync" in our script but it doesn't help. It works only 
> then we make one snapshot at a time. Even if we use "sync" before and 
> after creating snapshot, it doesn't help.
You might try 'btrfs filesystem sync' called on the filesystem the snapshots 
are being created on.  This works differently from the sync() syscall used by 
regular 'sync', and as a result forces metadata out as well as regular data 
(and it's almost certainly a metadata issue you are seeing), and it won't have 
as much impact on the rest of the system.


--
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: Problem with btrfs snapshots

[Austin S. Hemmelgarn]

On 2016-11-03 10:21, Peter Becker wrote:

(copy for mainlinglist)

2016-11-03 15:16 GMT+01:00 Дмитрий Нечаев :
Yes. We tried "sync" in our script but it doesn't help. It works only
then we make one snapshot at a time. Even if we use "sync" before and
after creating snapshot, it doesn't help.
You might try 'btrfs filesystem sync' called on the filesystem the 
snapshots are being created on.  This works differently from the sync() 
syscall used by regular 'sync', and as a result forces metadata out as 
well as regular data (and it's almost certainly a metadata issue you are 
seeing), and it won't have as much impact on the rest of the system.


--
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: Problem with btrfs snapshots

[Peter Becker]

(copy for mainlinglist)

2016-11-03 15:16 GMT+01:00 Дмитрий Нечаев :
Yes. We tried "sync" in our script but it doesn't help. It works only
then we make one snapshot at a time. Even if we use "sync" before and
after creating snapshot, it doesn't help.
--
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: Problem with btrfs snapshots

[Peter Becker]

Have you tryed "sync" between create several snapshots commands?

2016-11-03 13:22 GMT+01:00 Дмитрий Нечаев :
> Hello.
> We are have a strange situation with btrfs snapshot. We have a special
> script to create snapshot and if we create several snapshots in the same
> time we get ENOSPC error. But if we create snapshots one after another with
> a little pause between (about 10 minutes), then everything looks ok.
> Is there any command to determine that it is safe to make another snapshot?
>
> # uname -a
> Linux OraCI2.sigma-it.local 4.8.4-1.el7.elrepo.x86_64 #1 SMP Sat Oct 22
> 11:47:38 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux
> # btrfs --version
> btrfs-progs v4.8.1
> # btrfs fi show
> Label: 'BUILDS'  uuid: ce8952ff-30e5-48c5-8cd2-529c95667aa8
> Total devices 1 FS bytes used 356.82GiB
> devid1 size 1000.00GiB used 383.00GiB path /dev/nvme0n1p1
>
> Label: none  uuid: a712598d-cc4f-4dc5-bdfb-de7ae432b109
> Total devices 1 FS bytes used 4.71TiB
> devid1 size 7.66TiB used 4.96TiB path
> /dev/mapper/OraCI2-docker--data
>
> Label: none  uuid: 89c0495f-ed26-4d66-b83b-ffb5882bd082
> Total devices 1 FS bytes used 880.43GiB
> devid1 size 1.93TiB used 913.01GiB path /dev/nvme0n1p2
> # btrfs fi df /var/lib/docker/db/STANDS
> Data, single: total=4.89TiB, used=4.68TiB
> System, DUP: total=8.00MiB, used=592.00KiB
> Metadata, DUP: total=35.00GiB, used=26.29GiB
> GlobalReserve, single: total=512.00MiB, used=4.41MiB
>
> Best regards,
> Dmitry Nechaev
>
> С уважением,
> Дмитрий Нечаев,
> Ведущий инженер Группы сетевого и системного администрирования Отдела
> системной интеграции  ООО "СИГМА"
> Тел: +7 812 602 27 72 доб. 158
> Факс: +7 812 602 2770
> e-mail: d.nech...@sigma-it.ru
>
>
>
> --
> 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
--
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

Problem with btrfs snapshots

[Дмитрий Нечаев]

Hello.
We are have a strange situation with btrfs snapshot. We have a special
script to create snapshot and if we create several snapshots in the same
time we get ENOSPC error. But if we create snapshots one after another with
a little pause between (about 10 minutes), then everything looks ok.
Is there any command to determine that it is safe to make another snapshot?

# uname -a
Linux OraCI2.sigma-it.local 4.8.4-1.el7.elrepo.x86_64 #1 SMP Sat Oct 22
11:47:38 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux
# btrfs --version
btrfs-progs v4.8.1
# btrfs fi show
Label: 'BUILDS'  uuid: ce8952ff-30e5-48c5-8cd2-529c95667aa8
Total devices 1 FS bytes used 356.82GiB
devid1 size 1000.00GiB used 383.00GiB path /dev/nvme0n1p1

Label: none  uuid: a712598d-cc4f-4dc5-bdfb-de7ae432b109
Total devices 1 FS bytes used 4.71TiB
devid1 size 7.66TiB used 4.96TiB path
/dev/mapper/OraCI2-docker--data

Label: none  uuid: 89c0495f-ed26-4d66-b83b-ffb5882bd082
Total devices 1 FS bytes used 880.43GiB
devid1 size 1.93TiB used 913.01GiB path /dev/nvme0n1p2
# btrfs fi df /var/lib/docker/db/STANDS
Data, single: total=4.89TiB, used=4.68TiB
System, DUP: total=8.00MiB, used=592.00KiB
Metadata, DUP: total=35.00GiB, used=26.29GiB
GlobalReserve, single: total=512.00MiB, used=4.41MiB

Best regards,
Dmitry Nechaev

С уважением,
Дмитрий Нечаев,
Ведущий инженер Группы сетевого и системного администрирования Отдела
системной интеграции  ООО "СИГМА"
Тел: +7 812 602 27 72 доб. 158
Факс: +7 812 602 2770
e-mail: d.nech...@sigma-it.ru



--
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: Problem with btrfs fs in 4.1.25 (also 4.8.0) - getting EBUSY on file create - kernel.org bug 173001

[Dave Olson]

Dave Olson  wrote:

> The full details are in
> https://bugzilla.kernel.org/show_bug.cgi?id=173001
> 
> Basicly, logrotate has rotated a file to a new name, tries to open a new
> file with the original name, and gets EBUSY.  The file is not created.
> 
> Later on the file can be created with no problems.
> 
> I've turned on most of the BTRFS config options, and there are no BTRFS
> messages related to the failure.
> 
> The file is on the root filesystem.

This problem is also reproducible on a 4.8 kernel.org kernel with no
modifications, built today from the 4.8 tag.

It happened on the 77th powercycle, after about 3 hours.

Dave Olson
ol...@cumulusnetworks.com
--
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

Problem with btrfs fs in 4.1.25 - getting EBUSY on file create - kernel.org bug 173001

[Dave Olson]

The full details are in
https://bugzilla.kernel.org/show_bug.cgi?id=173001

Basicly, logrotate has rotated a file to a new name, tries to open a new
file with the original name, and gets EBUSY.  The file is not created.

Later on the file can be created with no problems.

I've turned on most of the BTRFS config options, and there are no BTRFS
messages related to the failure.

The file is on the root filesystem.


Dave Olson
ol...@cumulusnetworks.com
--
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: btrfs-transacti causing IO problem to btrfs (skinny-metadata?)

[Martin]

For anyone stumbling across this thread:

For my example, all was cleaned up by using the btrfs scrub:

btrfs scrub start /mountpoint


No data lost.

Good luck,
Martin


On 25/03/15 09:38, Martin wrote:

 
 Is that btrfs system formatted with a previous kernel (pre-
 skinny-metadata) and is now being used with a kernel that newly has
 skinny-metadata enabled by default?...
 
 
 I've stumbled across a bug/change/patch listed for a mixed pre/post
 skinny-metadata whereby you get to see lots of csum errors in the logs...
 
 For one 16TB btrfs raid1 system that brought things down to read-only...
 
 
 I'm now on kernel 3.18.9, and Btrfs v3.18.2. Presently copying the
 latest data onto a backup before trying a scrub! :-)
 
 LOTs of:
 
 kernel: parent transid verify failed on 5992676900864 wanted 70743 found
 70709
 kernel: parent transid verify failed on 5992676900864 wanted 70743 found
 70709
 kernel: BTRFS info (device sdj): no csum found for inode 50675726 start
 16384
 kernel: BTRFS info (device sdj): csum failed ino 50675726 off 0 csum
 42383870 expected csum 0
 kernel: BTRFS info (device sdj): csum failed ino 50675726 off 4096 csum
 815939273 expected csum 0
 
 and variations seen.
 
 (Or advice for that one welcomed! ;-) )


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

btrfs-transacti causing IO problem to btrfs

[Ian Gordon]

Hello,

I have a btrfs filesystem which has been working ok for about 90days,
but on Monday it become very slow (takes about 6hours to rsync backup a
3GB Ubuntu server - despite minimal changes from previous backup). I
noticed, that even with no processes reading or writing to the
filesystem, that btrfs-transaci was writing to the disk (averaging at
about 5MB/s) for a few hours before stopping until I wrote to the
filesystem again and then the process would repeat.

The btrfs filesystem uses skinny-metadata and is mounted with relatime
It has 744 subvolumes (of which about 700 are readonly snapshots)

Any ideas? Is there some sort of cleanup getting automatically run in
the background?

 * Linux hutton-cis.cc.strath.ac.uk 3.16.0-30-generic #40~14.04.1-Ubuntu
SMP Thu Jan 15 17:43:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
 * Btrfs v3.12
 * Label: none  uuid: a3e49694-a66d-4c0d-b5bd-d2b7ced68535
Total devices 1 FS bytes used 4.59TiB
devid1 size 8.76TiB used 4.77TiB path /dev/dm-0
 * Data, single: total=4.41TiB, used=4.41TiB
   System, DUP: total=8.00MiB, used=544.00KiB
   System, single: total=4.00MiB, used=0.00
   Metadata, DUP: total=186.00GiB, used=184.17GiB
   Metadata, single: total=8.00MiB, used=0.00
   unknown, single: total=512.00MiB, used=16.30MiB
 * There is nothing logged in dmesg except for the standard boot
   messages

Thanks for any help anyone can be,

-- 
Ian Gordon,
Department of Computer and Information Sciences,
University of Strathclyde.
Tel: 0141 548 3592Fax: 0141 548 4523Room: LT1307
The University of Strathclyde is a charitable body, registered in
Scotland, with registration number SC015263.
--
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: btrfs-transacti causing IO problem to btrfs (skinny-metadata?)

[Martin]

On 25/03/15 08:29, Ian Gordon wrote:
 
 Hello,
 
 I have a btrfs filesystem which has been working ok for about 90days,
 but on Monday it become very slow (takes about 6hours to rsync backup a
 3GB Ubuntu server - despite minimal changes from previous backup). I
 noticed, that even with no processes reading or writing to the
 filesystem, that btrfs-transaci was writing to the disk (averaging at
 about 5MB/s) for a few hours before stopping until I wrote to the
 filesystem again and then the process would repeat.
 
 The btrfs filesystem uses skinny-metadata and is mounted with relatime
 It has 744 subvolumes (of which about 700 are readonly snapshots)
 
 Any ideas? Is there some sort of cleanup getting automatically run in
 the background?

Is that btrfs system formatted with a previous kernel (pre-
skinny-metadata) and is now being used with a kernel that newly has
skinny-metadata enabled by default?...


I've stumbled across a bug/change/patch listed for a mixed pre/post
skinny-metadata whereby you get to see lots of csum errors in the logs...

For one 16TB btrfs raid1 system that brought things down to read-only...


I'm now on kernel 3.18.9, and Btrfs v3.18.2. Presently copying the
latest data onto a backup before trying a scrub! :-)

LOTs of:

kernel: parent transid verify failed on 5992676900864 wanted 70743 found
70709
kernel: parent transid verify failed on 5992676900864 wanted 70743 found
70709
kernel: BTRFS info (device sdj): no csum found for inode 50675726 start
16384
kernel: BTRFS info (device sdj): csum failed ino 50675726 off 0 csum
42383870 expected csum 0
kernel: BTRFS info (device sdj): csum failed ino 50675726 off 4096 csum
815939273 expected csum 0

and variations seen.

(Or advice for that one welcomed! ;-) )


Cheers,
Martin


--
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: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[Phillip Susi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/9/2014 10:10 PM, Anand Jain wrote:
 In the test case provided earlier who is triggering the scan ? 
 grub-probe ?

The scan is initiated by udev.  grub-probe only comes into it because
it is looking to /proc/mounts to find out what device is mounted, and
/proc/mounts is lieing.

 But we had to revert, Since btrfs bug become a feature for the
 system boot process and fixing that breaks mount at boot with
 subvol.

How is this?  Also are we talking about updating the cached list of
devices that *can* be mounted, or what device already *is* mounted?  I
can see doing the former, but the latter should never happen.

 if the device is already mounted, just the device path is updated 
 but still the original device will be still in use (bug).

Yep, that is the bug that started all of this.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUiG1MAAoJENRVrw2cjl5Rm0gIAJ6sq72zKSEfCuCjigknx25T
a97wjtMeb+yeaECc5FfwN7Fm454GSSuj6RFCRVjo3sCgJP3sUEH49syJnvW1QiEP
A5ktXfTpz6/zaeP9DbGPDCiVix0RdsJ6bCjP/8InsASueXOENCpxxmblxrbE4Wxj
Mdz8lu9L8G+fc6btbLLb0N4i0clSiImQds90zTQ1cXihJ/4wUIO3qgq+rruSYMqI
A182FS7NTUQrRcJ/rbcha3dCyD/urbCaRTUztMvTnSs3a7hK5p+SBNbfxEORC6ni
HrRMxpOlgHOTMnL3EHw843OuGv0Us3VqVbuPG3K6L4+G4W1sFxgKEAnLvEbjzAI=
=Vpre
-END PGP SIGNATURE-
--
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: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[Phillip Susi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/8/2014 5:25 PM, Konstantin wrote:
 
 Phillip Susi schrieb am 08.12.2014 um 15:59:
 The bios does not know or care about partitions.  All you need is
 a
 That's only true for older BIOSs. With current EFI boards they not
 only care but some also mess around with GPT partition tables.

EFI is a whole other beast that we aren't talking about.

 partition table in the MBR and you can install grub there and
 have it boot the system from a mdadm 1.1 or 1.2 format array
 housed in a partition on the rest of the disk.  The only time you
 really *have* to
 I was thinking of this solution as well but as I'm not aware of
 any partitioning tool caring about mdadm metadata so I rejected it.
 It requires a non-standard layout leaving reserved empty spaces for
 mdadm metadata. It's possible but it isn't documented so far I know
 and before losing hours of trying I chose the obvious one.

What on earth are you talking about?  Partitioning tool that cares
about mdadm?  non-standard layout?  I am talking about the bog
standard layout where you create a partition, then use that partition
to build an mdadm array.  mdadm takes care of its own metadata.  There
isn't anything unusual, non obvious, or undocumented here.

 use 0.9 or 1.0 ( and you really should be using 1.0 instead since
 it handles larger arrays and can't be confused vis. whole disk
 vs. partition components ) is if you are running a raid1 on the
 raw disk, with no partition table and then partition inside the
 array instead, and really, you just shouldn't be doing that.
 That's exactly what I want to do - running RAID1 on the whole disk
 as most hardware based RAID systems do. Before that I was running
 RAID on disk partitions for some years but this was quite a pain in
 comparison. Hot(un)plugging a drive brings you a lot of issues with
 failing mdadm commands as they don't like concurrent execution when
 the same physical device is affected. And rebuild of RAID
 partitions is done sequentially with no deterministic order. We
 could talk for hours about that but if interested maybe better in
 private as it is not BTRFS related.

So don't create more than one raid partition on the disk.

 dmraid solves the problem by removing the partitions from the 
 underlying physical device ( /dev/sda ), and only exposing them
 on the array ( /dev/mapper/whatever ).  LVM only has the problem
 when you take a snapshot.  User space tools face the same issue
 and they resolve it by ignoring or deprioritizing the snapshot.
 I don't agree. dmraid and mdraid both remove the partitions. This
 is not a solution BTRFS will still crash the PC using
 /dev/mapper/whatever or whatever device appears in the system
 providing the BTRFS volume.

You just said btrfs will crash by accessing the *correct* volume after
the *incorrect* one has been removed.  You aren't making any sense.
The problem only arises when the same partition is visible on *both*
the raw disk, and the md device.

 Speaking of BTRFS tools, I am still somehow confused that the
 problem confusing or mixing devices happens at all. I don't know
 the metadata of a BTRFS RAID setup but I assume there must be
 something like a drive index in there, as the order of RAID5 drives
 does matter. So having a second device with identical metadata
 should be considered invalid for auto-adding anyway.

Again, the problem is when you first boot up and/or mount the volume.
 Which of the duplicate devices shows up first is indeterminate so
just saying ignore the second one doesn't help.  Even saying well
error out if there are two doesn't help since that leaves open a race
condition where the second volume has not appeared yet at the time you
do the check.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUhx16AAoJENRVrw2cjl5R+IYH/R+ftOiy444+W/K+C0cFKBdi
RlMa2Op9Q0322Rae1IiJvkX/TPUQEnr7sFXcOIhYL9/HKB8zGMr+CQq+9rq8lGdB
QurLcI0MpWbwZZCJCTzrJxRBqqPOXKJ1aU9vWLuuGhS9tCdkfxfy9qcXPnmC2Qta
PfN1Qlr4Invb3Kb/NuB2w7S4nhzYLgBa1KgBDm3EWdCzG03WHMAxwSiBgMvf3nzc
DJ/JMF5TP70760yrlWCvFIa1fgWbGVp7fT9yArDab8N53FYAuE8WIunn+g1hHyue
MTF5ZPhEjVKUVHY1Tl1dqdv0i35TXCbXiVwCwk02veV2+lf95zeNcynmB9kUiSc=
=gvB2
-END PGP SIGNATURE-
--
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: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[Anand Jain]

On 08/12/2014 22:59, Phillip Susi wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/7/2014 7:32 PM, Konstantin wrote:

I'm guessing you are using metadata format 0.9 or 1.0, which put
the metadata at the end of the drive and the filesystem still
starts in sector zero.  1.2 is now the default and would not have
this problem as its metadata is at the start of the disk ( well,
4k from the start ) and the fs starts further down.

I know this and I'm using 0.9 on purpose. I need to boot from
these disks so I can't use 1.2 format as the BIOS wouldn't
recognize the partitions. Having an additional non-RAID disk for
booting introduces a single point of failure which contrary to the
idea of RAID0.


The bios does not know or care about partitions.  All you need is a
partition table in the MBR and you can install grub there and have it
boot the system from a mdadm 1.1 or 1.2 format array housed in a
partition on the rest of the disk.  The only time you really *have* to
use 0.9 or 1.0 ( and you really should be using 1.0 instead since it
handles larger arrays and can't be confused vis. whole disk vs.
partition components ) is if you are running a raid1 on the raw disk,
with no partition table and then partition inside the array instead,
and really, you just shouldn't be doing that.


Anyway, to avoid a futile discussion, mdraid and its format is not
the problem, it is just an example of the problem. Using dm-raid
would do the same trouble, LVM apparently, too. I could think of a
bunch of other cases including the use of hardware based RAID
controllers. OK, it's not the majority's problem, but that's not
the argument to keep a bug/flaw capable of crashing your system.


dmraid solves the problem by removing the partitions from the
underlying physical device ( /dev/sda ), and only exposing them on the
array ( /dev/mapper/whatever ).  LVM only has the problem when you
take a snapshot.  User space tools face the same issue and they
resolve it by ignoring or deprioritizing the snapshot.


As it is a nice feature that the kernel apparently scans for drives
and automatically identifies BTRFS ones, it seems to me that this
feature is useless. When in a live system a BTRFS RAID disk fails,
it is not sufficient to hot-replace it, the kernel will not
automatically rebalance. Commands are still needed for the task as
are with mdraid. So the only point I can see at the moment where
this auto-detect feature makes sense is when mounting the device
for the first time. If I remember the documentation correctly, you
mount one of the RAID devices and the others are automagically
attached as well. But outside of the mount process, what is this
auto-detect used for?

So here a couple of rather simple solutions which, as far as I can
see, could solve the problem:

1. Limit the auto-detect to the mount process and don't do it when
devices are appearing.


 In the test case provided earlier who is triggering the scan ?
 grub-probe ?



2. When a BTRFS device is detected and its metadata is identical to
one already mounted, just ignore it.


 Seems like patch:
   commit b96de000bc8bc9688b3a2abea4332bd57648a49f
   Author: Anand Jain anand.j...@oracle.com
   Date:   Thu Jul 3 18:22:05 2014 +0800

 Btrfs: device_list_add() should not update list when mounted


But we had to revert, Since btrfs bug become a feature for the system 
boot process and fixing that breaks mount at boot with subvol.


 commit 0f23ae74f589304bf33233f85737f4fd368549eb
 Author: Chris Mason c...@fb.com
 Date:   Thu Sep 18 07:49:05 2014 -0700

   Revert Btrfs: device_list_add() should not update list when mounted

 This reverts commit b96de000bc8bc9688b3a2abea4332bd57648a49f.



That doesn't really solve the problem since you can still pick the
wrong one to mount in the first place.


 The question is does both device has same generation number ?
 if not then this fix will take care of picking the device
 with larger generation number it during mount.

commit 77bdae4d136e167bab028cbec58b988f91cf73c0
Author: Anand Jain anand.j...@oracle.com
Date:   Thu Jul 3 18:22:06 2014 +0800

btrfs: check generation as replace duplicates devid+uuid


 Yes if there are two devices with the same
   fsid + devid + uuid + generation

 then it use last probed during mount.
 OR
 if the device is already mounted, just the device path is updated
 but still the original device will be still in use (bug).

Thanks



-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUhbztAAoJENRVrw2cjl5RomkH/26Q3M6LXVaF0qEcEzFTzGEL
uVAOKBY040Ui5bSK0WQYnH0XtE8vlpLSFHxrRa7Ygpr3jhffSsu6ZsmbOclK64ZA
Z8rNEmRFhOxtFYTcQwcUbeBtXEN3k/5H49JxbjUDItnVPBoeK3n7XG4i1Lap5IdY
GXyLbh7ogqd/p+wX6Om20NkJSx4xzyU85E4ZvDADQA+2RIBaXva5tDPx5/UD4XBQ
h8ai+wS1iC8EySKxwKBEwzwb7+Z6w7nOWO93v/lL34fwTg0OIY9uEfTaAy5KcDjz
z6QXWTmvrbiFpyy/qyGSqBGlPjZ+r98mVEDbYWCVfK8AoD6UmteD7R8WAWkWiWY=
=PJww
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the 

Re: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[Phillip Susi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/7/2014 7:32 PM, Konstantin wrote:
 I'm guessing you are using metadata format 0.9 or 1.0, which put
 the metadata at the end of the drive and the filesystem still
 starts in sector zero.  1.2 is now the default and would not have
 this problem as its metadata is at the start of the disk ( well,
 4k from the start ) and the fs starts further down.
 I know this and I'm using 0.9 on purpose. I need to boot from
 these disks so I can't use 1.2 format as the BIOS wouldn't
 recognize the partitions. Having an additional non-RAID disk for
 booting introduces a single point of failure which contrary to the
 idea of RAID0.

The bios does not know or care about partitions.  All you need is a
partition table in the MBR and you can install grub there and have it
boot the system from a mdadm 1.1 or 1.2 format array housed in a
partition on the rest of the disk.  The only time you really *have* to
use 0.9 or 1.0 ( and you really should be using 1.0 instead since it
handles larger arrays and can't be confused vis. whole disk vs.
partition components ) is if you are running a raid1 on the raw disk,
with no partition table and then partition inside the array instead,
and really, you just shouldn't be doing that.

 Anyway, to avoid a futile discussion, mdraid and its format is not
 the problem, it is just an example of the problem. Using dm-raid
 would do the same trouble, LVM apparently, too. I could think of a
 bunch of other cases including the use of hardware based RAID
 controllers. OK, it's not the majority's problem, but that's not
 the argument to keep a bug/flaw capable of crashing your system.

dmraid solves the problem by removing the partitions from the
underlying physical device ( /dev/sda ), and only exposing them on the
array ( /dev/mapper/whatever ).  LVM only has the problem when you
take a snapshot.  User space tools face the same issue and they
resolve it by ignoring or deprioritizing the snapshot.

 As it is a nice feature that the kernel apparently scans for drives
 and automatically identifies BTRFS ones, it seems to me that this
 feature is useless. When in a live system a BTRFS RAID disk fails,
 it is not sufficient to hot-replace it, the kernel will not
 automatically rebalance. Commands are still needed for the task as
 are with mdraid. So the only point I can see at the moment where
 this auto-detect feature makes sense is when mounting the device
 for the first time. If I remember the documentation correctly, you
 mount one of the RAID devices and the others are automagically
 attached as well. But outside of the mount process, what is this
 auto-detect used for?
 
 So here a couple of rather simple solutions which, as far as I can
 see, could solve the problem:
 
 1. Limit the auto-detect to the mount process and don't do it when 
 devices are appearing.
 
 2. When a BTRFS device is detected and its metadata is identical to
 one already mounted, just ignore it.

That doesn't really solve the problem since you can still pick the
wrong one to mount in the first place.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUhbztAAoJENRVrw2cjl5RomkH/26Q3M6LXVaF0qEcEzFTzGEL
uVAOKBY040Ui5bSK0WQYnH0XtE8vlpLSFHxrRa7Ygpr3jhffSsu6ZsmbOclK64ZA
Z8rNEmRFhOxtFYTcQwcUbeBtXEN3k/5H49JxbjUDItnVPBoeK3n7XG4i1Lap5IdY
GXyLbh7ogqd/p+wX6Om20NkJSx4xzyU85E4ZvDADQA+2RIBaXva5tDPx5/UD4XBQ
h8ai+wS1iC8EySKxwKBEwzwb7+Z6w7nOWO93v/lL34fwTg0OIY9uEfTaAy5KcDjz
z6QXWTmvrbiFpyy/qyGSqBGlPjZ+r98mVEDbYWCVfK8AoD6UmteD7R8WAWkWiWY=
=PJww
-END PGP SIGNATURE-
--
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: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[Robert White]

On 12/07/2014 04:32 PM, Konstantin wrote:

I know this and I'm using 0.9 on purpose. I need to boot from these
disks so I can't use 1.2 format as the BIOS wouldn't recognize the
partitions. Having an additional non-RAID disk for booting introduces a
single point of failure which contrary to the idea of RAID0.


GRUB2 has raid 1.1 and 1.2 metadata support via the mdraid1x module. LVM 
is also supported. I don't know if a stack of both is supported.


There is, BTW, no such thing as a (commodity) computer without a single 
point of failure in it somewhere. I've watched government contracts 
chase this demon for decades. Be it disk, controller, network card, bus 
chip, cpu or stick-of-ram you've got a single point of failure 
somewhere. Actually you likely have several such points of potential 
failure.


For instance, are you _sure_ your BIOS is going to check the second 
drive if it gets read failure after starting in on your first drive? 
Chances are it won't because that four-hundred bytes-or-so boot loader 
on that first disk has no way to branch back into the bios.


You can waste a lot of your life chasing that ghost and you'll still 
discover you've missed it and have to whip out your backup boot media.


It may well be worth having a second copy of /boot around, but make sure 
you stay out of bandersnatch territory when designing your system. The 
more you over-think the plumbing, the easier it is to stop up the pipes.

--
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: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[Konstantin]

Phillip Susi schrieb am 08.12.2014 um 15:59:
 On 12/7/2014 7:32 PM, Konstantin wrote:
  I'm guessing you are using metadata format 0.9 or 1.0, which put
  the metadata at the end of the drive and the filesystem still
  starts in sector zero.  1.2 is now the default and would not have
  this problem as its metadata is at the start of the disk ( well,
  4k from the start ) and the fs starts further down.
  I know this and I'm using 0.9 on purpose. I need to boot from
  these disks so I can't use 1.2 format as the BIOS wouldn't
  recognize the partitions. Having an additional non-RAID disk for
  booting introduces a single point of failure which contrary to the
  idea of RAID0.

 The bios does not know or care about partitions.  All you need is a
That's only true for older BIOSs. With current EFI boards they not only
care but some also mess around with GPT partition tables.
 partition table in the MBR and you can install grub there and have it
 boot the system from a mdadm 1.1 or 1.2 format array housed in a
 partition on the rest of the disk.  The only time you really *have* to
I was thinking of this solution as well but as I'm not aware of any
partitioning tool caring about mdadm metadata so I rejected it. It
requires a non-standard layout leaving reserved empty spaces for mdadm
metadata. It's possible but it isn't documented so far I know and before
losing hours of trying I chose the obvious one.
 use 0.9 or 1.0 ( and you really should be using 1.0 instead since it
 handles larger arrays and can't be confused vis. whole disk vs.
 partition components ) is if you are running a raid1 on the raw disk,
 with no partition table and then partition inside the array instead,
 and really, you just shouldn't be doing that.
That's exactly what I want to do - running RAID1 on the whole disk as
most hardware based RAID systems do. Before that I was running RAID on
disk partitions for some years but this was quite a pain in comparison.
Hot(un)plugging a drive brings you a lot of issues with failing mdadm
commands as they don't like concurrent execution when the same physical
device is affected. And rebuild of RAID partitions is done sequentially
with no deterministic order. We could talk for hours about that but if
interested maybe better in private as it is not BTRFS related.
  Anyway, to avoid a futile discussion, mdraid and its format is not
  the problem, it is just an example of the problem. Using dm-raid
  would do the same trouble, LVM apparently, too. I could think of a
  bunch of other cases including the use of hardware based RAID
  controllers. OK, it's not the majority's problem, but that's not
  the argument to keep a bug/flaw capable of crashing your system.

 dmraid solves the problem by removing the partitions from the
 underlying physical device ( /dev/sda ), and only exposing them on the
 array ( /dev/mapper/whatever ).  LVM only has the problem when you
 take a snapshot.  User space tools face the same issue and they
 resolve it by ignoring or deprioritizing the snapshot.
I don't agree. dmraid and mdraid both remove the partitions. This is not
a solution BTRFS will still crash the PC using /dev/mapper/whatever or
whatever device appears in the system providing the BTRFS volume.
  As it is a nice feature that the kernel apparently scans for drives
  and automatically identifies BTRFS ones, it seems to me that this
  feature is useless. When in a live system a BTRFS RAID disk fails,
  it is not sufficient to hot-replace it, the kernel will not
  automatically rebalance. Commands are still needed for the task as
  are with mdraid. So the only point I can see at the moment where
  this auto-detect feature makes sense is when mounting the device
  for the first time. If I remember the documentation correctly, you
  mount one of the RAID devices and the others are automagically
  attached as well. But outside of the mount process, what is this
  auto-detect used for?

  So here a couple of rather simple solutions which, as far as I can
  see, could solve the problem:

  1. Limit the auto-detect to the mount process and don't do it when
  devices are appearing.

  2. When a BTRFS device is detected and its metadata is identical to
  one already mounted, just ignore it.

 That doesn't really solve the problem since you can still pick the
 wrong one to mount in the first place.
Oh, it does solve the problem, you are are speaking of another problem
which is always there when having several disks in a system. Mounting
the wrong device can happen the case I'm describing if you use UUID,
label or some other metadata related information to mount it. You won't
try do that when you insert a disk you know it has the same metadata. It
will not happen (except user tools outsmart you ;-)) when using the
device name(s). I think it could be expected from a user mounting things
manually to know or learn which device node is which drive. On the other
hand in my case one of the drives is already mounted so getting it

Re: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[Konstantin]

Robert White schrieb am 08.12.2014 um 18:20:
 On 12/07/2014 04:32 PM, Konstantin wrote:
 I know this and I'm using 0.9 on purpose. I need to boot from these
 disks so I can't use 1.2 format as the BIOS wouldn't recognize the
 partitions. Having an additional non-RAID disk for booting introduces a
 single point of failure which contrary to the idea of RAID0.

 GRUB2 has raid 1.1 and 1.2 metadata support via the mdraid1x module.
 LVM is also supported. I don't know if a stack of both is supported.

 There is, BTW, no such thing as a (commodity) computer without a
 single point of failure in it somewhere. I've watched government
 contracts chase this demon for decades. Be it disk, controller,
 network card, bus chip, cpu or stick-of-ram you've got a single point
 of failure somewhere. Actually you likely have several such points of
 potential failure.

 For instance, are you _sure_ your BIOS is going to check the second
 drive if it gets read failure after starting in on your first drive?
 Chances are it won't because that four-hundred bytes-or-so boot loader
 on that first disk has no way to branch back into the bios.

 You can waste a lot of your life chasing that ghost and you'll still
 discover you've missed it and have to whip out your backup boot media.

 It may well be worth having a second copy of /boot around, but make
 sure you stay out of bandersnatch territory when designing your
 system. The more you over-think the plumbing, the easier it is to
 stop up the pipes.
You are right, there is as good as always a single point of failure
somewhere, even if it is the power plant providing your electricity ;-).
I should have written introduces an additional single point of failure
to be 100% correct but I thought this was obvious. As I have replaced
dozens of damaged hard disks but only a few CPUs, RAMs etc. it is more
important for me to reduce the most frequent and easy-to-solve points of
failure. For more important systems there are high availability
solutions which alleviate many of the problems you mention of but that's
not the point here when speaking about the major bug in BTRFS which can
make your system crash.


--
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: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[Robert White]

On 12/08/2014 02:38 PM, Konstantin wrote:

For more important systems there are high availability
solutions which alleviate many of the problems you mention of but that's
not the point here when speaking about the major bug in BTRFS which can
make your system crash.


I think you missed the part where I told you that you could use GRUB2 
and then you could use the 1.2 metadata on your raid and then have you 
system work as desired.


Trying to make this all about BTRFS is more than a touch disingenuous as 
you are doing things that can make many systems fail in exactly the same 
way.


Undefined behavior is undefined.

The MDADM people made the latter metadata layouts to address your issue, 
and its up to you to use it. Need it to boot, GRUB2 will boot it, and 
it's up to you to use it.


New software fixes problems evident in the old, but once you decide to 
stick with the old despite the new, your problem becomes uninteresting 
because it was already fixed.


So yes, if you use the woefully out of date metadata and boot loader you 
will have problems. If you use the distro scripts that scan the volumes 
you don't want scanned, you will have problems. People are working on 
making sure that those problems have work arounds. And sometimes the 
work around for doctor, it hurts when I do this is don't do that any 
more.


It is multiplicatively impossible to build BTRFS such that it can dance 
through the entire Cartesian Product of all possible storage management 
solutions. Just as it was impossible for LVM and MDADM before them. If 
your system is layered, _you_ bear the burden of making sure that the 
layers are applied. Each tool is evolving to help you, but its still you 
doing the system design.


GRUB has put in modules for everything you need (so far) to boot. mdadm 
has better signatures if you use them. LVM always had device offsets 
built into its metadata block.


But answering the negative. The sort of question that might be phrased 
how do you know it's _not_ mdadm old style signatures is an unbounded 
coding, not because any one is impossible to code, but because an 
endless stream of possibilities is coming in the pipe. A striped storage 
controller might make a system look like /dev/sdb is a stand-alone BTRFS 
file system if the controller doesn't start and the mdadm and lvm 
signatures are on /dev/sda and take up just the right amount of room.


If I do an mkfs.ext2 on a media, then do a cryptsetup luksCreate on that 
same media, I can mount it either way, with disastrous consequences for 
the other semantic layout.


The bad combinations available are virtually limitless.

There comes a point where the System Architect that decided how to build 
the individual system has to take responsibility for his actions.


Note that the same it didn't protect me errors can happen _easily_ 
with other filesystems. Try building an NTFS on a disk, then build an 
ext4 on the same disk then mount as either or both. (though now days you 
may need to build the ext4 then the NTFS since I think mkfs.ext4 may now 
have a little dedicated wiper to de-NTFS a disk after that went sour a 
few too many times).


When storage signatures conflict you will get exciting outcomes. It 
will always be that way, and its not an error in any of that 
filesystem code. You, the System Architect, bear a burden here.


The system isn't shooting itself when you do certain things. The 
System Architect is shooting the system with a bad layout bullet.


You don't want some LV to be scanned... don't scan it... If your tools 
scan it automatically, don't use those tools that way. But my distro 
automatically is just a reason to look twice at your distro or your design.



--
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: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[Konstantin]

Anand Jain wrote on 02.12.2014 at 12:54:



 On 02/12/2014 19:14, Goffredo Baroncelli wrote:
 I further investigate this issue.

 MegaBrutal, reported the following issue: doing a lvm snapshot of the
 device of a
 mounted btrfs fs, the new snapshot device name replaces the name of
 the original
 device in the output of /proc/mounts. This confused tools like
 grub-probe which
 report a wrong root device.

 very good test case indeed thanks.

 Actual IO would still go to the original device, until FS is remounted.
This seems to be correct at least at the beginning but I wouldn't be so
sure - why else the system is crashing in my case after a while when the
second drive is present?! So if the kernel was not using it in some way,
except the wrong /proc/mounts nothing else should happen.


 It has to be pointed out that instead the link under
 /sys/fs/btrfs/fsid/devices is
 correct.

 In this context the above sysfs path will be out of sync with the
 reality, its just stale sysfs entry.


 What happens is that *even if the filesystem is mounted*, doing a
 btrfs dev scan of a snapshot (of the real volume), the device name
 of the
 filesystem is replaced with the snapshot one.

 we have some fundamentally wrong stuff. My original patch tried
 to fix it. But later discovered that some external entities like
 systmed and boot process is using that bug as a feature and we had
 to revert the patch.

 Fundamentally scsi inquiry serial number is only number which is unique
 to the device (including the virtual device, but there could be some
 legacy virtual device which didn't follow that strictly, Anyway those
 I deem to be device side issue.) Btrfs depends on the combination of
 fsid, uuid and devid (and generation number) to identify the unique
 device volume, which is weak and easy to go wrong.


 Anand, with b96de000b, tried to fix it; however further regression
 appeared
 and Chris reverted this commit (see below).

 BR
 G.Baroncelli

 commit b96de000bc8bc9688b3a2abea4332bd57648a49f
 Author: Anand Jain anand.j...@oracle.com
 Date:   Thu Jul 3 18:22:05 2014 +0800

  Btrfs: device_list_add() should not update list when mounted
 [...]


 commit 0f23ae74f589304bf33233f85737f4fd368549eb
 Author: Chris Mason c...@fb.com
 Date:   Thu Sep 18 07:49:05 2014 -0700

  Revert Btrfs: device_list_add() should not update list when
 mounted

  This reverts commit b96de000bc8bc9688b3a2abea4332bd57648a49f.

  This commit is triggering failures to mount by subvolume id in some
  configurations.  The main problem is how many different ways this
  scanning function is used, both for scanning while mounted and
  unmounted.  A proper cleanup is too big for late rcs.

 [...]

 On 12/02/2014 09:28 AM, MegaBrutal wrote:
 2014-12-02 8:50 GMT+01:00 Goffredo Baroncelli kreij...@inwind.it:
 On 12/02/2014 01:15 AM, MegaBrutal wrote:
 2014-12-02 0:24 GMT+01:00 Robert White rwh...@pobox.com:
 On 12/01/2014 02:10 PM, MegaBrutal wrote:

 Since having duplicate UUIDs on devices is not a problem for me
 since
 I can tell them apart by LVM names, the discussion is of little
 relevance to my use case. Of course it's interesting and I like to
 read it along, it is not about the actual problem at hand.


 Which is why you use the device= mount option, which would take
 LVM names
 and which was repeatedly discussed as solving this very problem.

 Once you decide to duplicate the UUIDs with LVM snapshots you
 take up the
 burden of disambiguating your storage.

 Which is part of why re-reading was suggested as this was covered
 in some
 depth and _is_ _exactly_ about the problem at hand.

 Nope.

 root@reproduce-1391429:~# cat /proc/cmdline
 BOOT_IMAGE=/vmlinuz-3.18.0-031800rc5-generic
 root=/dev/mapper/vg-rootlv ro
 rootflags=device=/dev/mapper/vg-rootlv,subvol=@

 Observe, device= mount option is added.

 device= options is needed only in a btrfs multi-volume scenario.
 If you have only one disk, this is not needed


 I know. I only did this as a demonstration for Robert. He insisted it
 will certainly solve the problem. Well, it doesn't.



 root@reproduce-1391429:~# ./reproduce-1391429.sh
 #!/bin/sh -v
 lvs
LV VG   Attr  LSize   Pool Origin Data%  Move Log
 Copy%  Convert
rootlv vg   -wi-ao---   1.00g
swap0  vg   -wi-ao--- 256.00m

 grub-probe --target=device /
 /dev/mapper/vg-rootlv

 grep  /  /proc/mounts
 rootfs / rootfs rw 0 0
 /dev/dm-1 / btrfs rw,relatime,space_cache 0 0

 lvcreate --snapshot --size=128M --name z vg/rootlv
Logical volume z created

 lvs
LV VG   Attr  LSize   Pool Origin Data%  Move Log
 Copy%  Convert
rootlv vg   owi-aos--   1.00g
swap0  vg   -wi-ao--- 256.00m
z  vg   swi-a-s-- 128.00m  rootlv   0.11

 ls -l /dev/vg/
 total 0
 lrwxrwxrwx 1 root root 7 Dec  2 00:12 rootlv - ../dm-1
 lrwxrwxrwx 1 root root 7 Dec  2 00:12 swap0 - ../dm-0
 lrwxrwxrwx 1 root root 7 Dec  2 00:12 z - ../dm-2

 grub-probe --target=device /
 /dev/mapper/vg-z

 grep  /  

Re: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[Konstantin]

Phillip Susi wrote on 02.12.2014 at 20:19:
 On 12/1/2014 4:45 PM, Konstantin wrote:
  The bug appears also when using mdadm RAID1 - when one of the
  drives is detached from the array then the OS discovers it and
  after a while (not directly, it takes several minutes) it appears
  under /proc/mounts: instead of /dev/md0p1 I see there /dev/sdb1.
  And usually after some hour or so (depending on system workload)
  the PC completely freezes. So discussion about the uniqueness of
  UUIDs or not, a crashing kernel is telling me that there is a
  serious bug.

 I'm guessing you are using metadata format 0.9 or 1.0, which put the
 metadata at the end of the drive and the filesystem still starts in
 sector zero.  1.2 is now the default and would not have this problem
 as its metadata is at the start of the disk ( well, 4k from the start
 ) and the fs starts further down.
I know this and I'm using 0.9 on purpose. I need to boot from these
disks so I can't use 1.2 format as the BIOS wouldn't recognize the
partitions. Having an additional non-RAID disk for booting introduces a
single point of failure which contrary to the idea of RAID0.

Anyway, to avoid a futile discussion, mdraid and its format is not the
problem, it is just an example of the problem. Using dm-raid would do
the same trouble, LVM apparently, too. I could think of a bunch of other
cases including the use of hardware based RAID controllers. OK, it's not
the majority's problem, but that's not the argument to keep a bug/flaw
capable of crashing your system.

As it is a nice feature that the kernel apparently scans for drives and
automatically identifies BTRFS ones, it seems to me that this feature is
useless. When in a live system a BTRFS RAID disk fails, it is not
sufficient to hot-replace it, the kernel will not automatically
rebalance. Commands are still needed for the task as are with mdraid. So
the only point I can see at the moment where this auto-detect feature
makes sense is when mounting the device for the first time. If I
remember the documentation correctly, you mount one of the RAID devices
and the others are automagically attached as well. But outside of the
mount process, what is this auto-detect used for?

So here a couple of rather simple solutions which, as far as I can see,
could solve the problem:

1. Limit the auto-detect to the mount process and don't do it when
devices are appearing.

2. When a BTRFS device is detected and its metadata is identical to one
already mounted, just ignore it.


--
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: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[MegaBrutal]

2014-12-04 6:15 GMT+01:00 Duncan 1i5t5.dun...@cox.net:

 Which is why I'm running an initramfs for the first time since I've
 switched to btrfs raid1 mode root, as I quit with initrds back before
 initramfs was an option.  An initramfs appended to the kernel image beats
 a separate initrd, but I'd still love to see the kernel commandline
 parsing fixed so it broke at the correct = in rootflags=device= (which
 seemed to be the problem, the kernel then didn't seem to recognize
 rootflags at all, as it was apparently seeing it as a parameter called
 rootflags=device, instead of rootflags), so I could be rid of the
 initramfs again.


Are you sure it isn't fixed? At least, it parses rootflags=subvol=@
well, which also has multiple = signs. And last time I've tried this,
and didn't cause any problems:
rootflags=device=/dev/mapper/vg-rootlv,subvol=@. Though device=
shouldn't have an effect in this case anyway, but I didn't get any
complaints against it. Though I use an initrd.
--
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: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[Duncan]

MegaBrutal posted on Thu, 04 Dec 2014 09:20:12 +0100 as excerpted:

 Are you sure it isn't fixed? At least, it parses rootflags=subvol=@
 well, which also has multiple = signs. And last time I've tried this,
 and didn't cause any problems:
 rootflags=device=/dev/mapper/vg-rootlv,subvol=@. Though device=
 shouldn't have an effect in this case anyway, but I didn't get any
 complaints against it. Though I use an initrd.

AFAIK lvm requires userspace anyway, thus an initr*, and once you have 
that initr* handling the lvm, it's almost certainly the initr* parsing 
the rootflags= from the kernel commandline as well.  So in that case the 
kernel doesn't /need/ to be able to parse rootflag=, as all it does is 
pass the kernel commandline straight thru to the initr*, which would 
seem, in your case at least, to parse it correctly.

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

--
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: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[Goffredo Baroncelli]

On 12/02/2014 08:11 PM, Phillip Susi wrote:
 On 12/2/2014 7:23 AM, Austin S Hemmelgarn wrote:
 Stupid thought, why don't we just add blacklisting based on device
 path like LVM has for pvscan?
 
 That isn't logic that belongs in the kernel, so that is going down the
 path of yanking out the device auto probing from btrfs and instead
 writing a mount.btrfs helper that can use policies like blacklisting
 to auto locate all of the correct devices and pass them all to the
 kernel at mount time.
 
I am thinking about that. Today the device discovery happens:
a) when a device appears, two udev rules run btrfs dev scan device

/lib/udev/rules.d/70-btrfs.rules
/lib/udev/rules.d/80-btrfs-lvm.rules

b) during the boot it is ran a btrfs device scan, which scan all 
the device (this happens in debian for other distros may be different)

c) after a btrfs.mkfs, which starts a device scan on each devices of
the new filesystem

d) by the user


Regarding a), the problem is simply solved adding a line like:

ENV{DM_UDEV_LOW_PRIORITY_FLAG}==1, GOTO=btrfs_end

Regarding c), it is not a problem

Regarding b) and d), the only solution that I found is to query the 
udev DB inside the btrfs dev scan program and to skip the devices
with DM_UDEV_LOW_PRIORITY_FLAG==1. But implementing this, it would 
solve all the points a), b), c), d) with one shot !


BR
G.Baroncelli

P.S.
This is the comment made by LVM by DM_UDEV_LOW_PRIORITY_FLAG:

/*
 * DM_UDEV_LOW_PRIORITY_FLAG is set in case we need to instruct the
 * udev rules to give low priority to the device that is currently
 * processed. For example, this provides a way to select which symlinks
 * could be overwritten by high priority ones if their names are equal.
 * Common situation is a name based on FS UUID while using origin and
 * snapshot devices.
 */
#define DM_UDEV_LOW_PRIORITY_FLAG 0x0010

https://git.fedorahosted.org/cgit/lvm2.git/tree/libdm/libdevmapper.h#n1969



-- 
gpg @keyserver.linux.it: Goffredo Baroncelli kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5
--
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: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[Phillip Susi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12/03/2014 03:24 AM, Goffredo Baroncelli wrote:
 I am thinking about that. Today the device discovery happens: a)
 when a device appears, two udev rules run btrfs dev scan
 device
 
 /lib/udev/rules.d/70-btrfs.rules 
 /lib/udev/rules.d/80-btrfs-lvm.rules
 
 b) during the boot it is ran a btrfs device scan, which scan all
  the device (this happens in debian for other distros may be
 different)
 
 c) after a btrfs.mkfs, which starts a device scan on each devices
 of the new filesystem
 
 d) by the user

Are you sure the kernel only gains awareness of btrfs volumes when
user space runs btrfs device scan?  If that is so then that means you
can not boot from a multi device btrfs root without using an
initramfs.  I thought the kernel auto scanned all devices if you tried
to mount a multi device volume, but if this is so, then yes, the udev
rules could be fixed to not call btrfs device scan on an lvm snapshot.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCgAGBQJUf9BpAAoJENRVrw2cjl5RgcQIALCGfplK/xgX/QaiRjNW96l2
DWNPQMIhPesci0gF7Th3sNboew0hrc3g6S0a55wAO12CBhMPdzHxHjd9iFVpKi9O
vzvU36XyzwdcPJkBqRdPJMT2kX+428gYUW7jkyC8usj5eSCyeiIodJuxirGDL5Nb
3TttEJOpbPHGlTzHjAqEcK2ybzYi9HCN3CD3fuLagP9n+4zmFE7tGaGglZ9+7P58
wZjlP5xKDCR4Cu5Hr+5ErrmT2EoOvFC+PLKOT8xXhD9Y2emk2AtuY+5l/w7I+SIS
42gTUqPOx/8AOxBhOhkI0pPO8eK7S/lP1LKoXF0WWHhX8CgJLIHwj5KniDYcjBA=
=HI90
-END PGP SIGNATURE-
--
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: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[Duncan]

Phillip Susi posted on Wed, 03 Dec 2014 22:09:29 -0500 as excerpted:

 Are you sure the kernel only gains awareness of btrfs volumes when user
 space runs btrfs device scan?  If that is so then that means you can not
 boot from a multi device btrfs root without using an initramfs.  I
 thought the kernel auto scanned all devices if you tried to mount a
 multi device volume, but if this is so, then yes, the udev rules could
 be fixed to not call btrfs device scan on an lvm snapshot.

That has indeed been the case in the past, and to my knowledge remains 
the case.

Unless it has changed in the last cycle or two (and I've not seen patches 
to that effect on the list nor any hint of such, so I doubt it) the 
kernel doesn't do any such scanning without userspace telling it to.  The 
device= mount option can be used instead, but it didn't work with 
rootflags= on the kernel commandline last I tried so for a multidevice 
btrfs root, yes, an initramfs/initrd is required.

Which is why I'm running an initramfs for the first time since I've 
switched to btrfs raid1 mode root, as I quit with initrds back before 
initramfs was an option.  An initramfs appended to the kernel image beats 
a separate initrd, but I'd still love to see the kernel commandline 
parsing fixed so it broke at the correct = in rootflags=device= (which 
seemed to be the problem, the kernel then didn't seem to recognize 
rootflags at all, as it was apparently seeing it as a parameter called 
rootflags=device, instead of rootflags), so I could be rid of the 
initramfs again.

FWIW, I'm using dracut to generate the cpio archive, which with the right 
kernel config options set, the kernel build process then appends to the 
kernel.  Dracut btrfs module enabled of course, most of the rest force-
disabled as I run a monolithic kernel so don't need module loading, etc.

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

--
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: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[MegaBrutal]

2014-12-02 8:50 GMT+01:00 Goffredo Baroncelli kreij...@inwind.it:
 On 12/02/2014 01:15 AM, MegaBrutal wrote:
 2014-12-02 0:24 GMT+01:00 Robert White rwh...@pobox.com:
 On 12/01/2014 02:10 PM, MegaBrutal wrote:

 Since having duplicate UUIDs on devices is not a problem for me since
 I can tell them apart by LVM names, the discussion is of little
 relevance to my use case. Of course it's interesting and I like to
 read it along, it is not about the actual problem at hand.


 Which is why you use the device= mount option, which would take LVM names
 and which was repeatedly discussed as solving this very problem.

 Once you decide to duplicate the UUIDs with LVM snapshots you take up the
 burden of disambiguating your storage.

 Which is part of why re-reading was suggested as this was covered in some
 depth and _is_ _exactly_ about the problem at hand.

 Nope.

 root@reproduce-1391429:~# cat /proc/cmdline
 BOOT_IMAGE=/vmlinuz-3.18.0-031800rc5-generic
 root=/dev/mapper/vg-rootlv ro
 rootflags=device=/dev/mapper/vg-rootlv,subvol=@

 Observe, device= mount option is added.

 device= options is needed only in a btrfs multi-volume scenario.
 If you have only one disk, this is not needed


I know. I only did this as a demonstration for Robert. He insisted it
will certainly solve the problem. Well, it doesn't.



 root@reproduce-1391429:~# ./reproduce-1391429.sh
 #!/bin/sh -v
 lvs
   LV VG   Attr  LSize   Pool Origin Data%  Move Log Copy%  Convert
   rootlv vg   -wi-ao---   1.00g
   swap0  vg   -wi-ao--- 256.00m

 grub-probe --target=device /
 /dev/mapper/vg-rootlv

 grep  /  /proc/mounts
 rootfs / rootfs rw 0 0
 /dev/dm-1 / btrfs rw,relatime,space_cache 0 0

 lvcreate --snapshot --size=128M --name z vg/rootlv
   Logical volume z created

 lvs
   LV VG   Attr  LSize   Pool Origin Data%  Move Log Copy%  Convert
   rootlv vg   owi-aos--   1.00g
   swap0  vg   -wi-ao--- 256.00m
   z  vg   swi-a-s-- 128.00m  rootlv   0.11

 ls -l /dev/vg/
 total 0
 lrwxrwxrwx 1 root root 7 Dec  2 00:12 rootlv - ../dm-1
 lrwxrwxrwx 1 root root 7 Dec  2 00:12 swap0 - ../dm-0
 lrwxrwxrwx 1 root root 7 Dec  2 00:12 z - ../dm-2

 grub-probe --target=device /
 /dev/mapper/vg-z

 grep  /  /proc/mounts
 rootfs / rootfs rw 0 0
 /dev/dm-2 / btrfs rw,relatime,space_cache 0 0

 What /proc/self/mountinfo contains ?

Before creating snapshot:

15 20 0:15 / /sys rw,nosuid,nodev,noexec,relatime - sysfs sysfs rw
16 20 0:3 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
17 20 0:5 / /dev rw,relatime - devtmpfs udev
rw,size=241692k,nr_inodes=60423,mode=755
18 17 0:12 / /dev/pts rw,nosuid,noexec,relatime - devpts devpts
rw,gid=5,mode=620,ptmxmode=000
19 20 0:16 / /run rw,nosuid,noexec,relatime - tmpfs tmpfs
rw,size=50084k,mode=755
20 0 0:17 /@ / rw,relatime - btrfs /dev/dm-1 rw,space_cache
- THIS!
21 15 0:20 / /sys/fs/cgroup rw,relatime - tmpfs none rw,size=4k,mode=755
22 15 0:21 / /sys/fs/fuse/connections rw,relatime - fusectl none rw
23 15 0:6 / /sys/kernel/debug rw,relatime - debugfs none rw
24 15 0:10 / /sys/kernel/security rw,relatime - securityfs none rw
25 19 0:22 / /run/lock rw,nosuid,nodev,noexec,relatime - tmpfs none
rw,size=5120k
26 19 0:23 / /run/shm rw,nosuid,nodev,relatime - tmpfs none rw
27 19 0:24 / /run/user rw,nosuid,nodev,noexec,relatime - tmpfs none
rw,size=102400k,mode=755
28 15 0:25 / /sys/fs/pstore rw,relatime - pstore none rw
29 20 253:1 / /boot rw,relatime - ext2 /dev/vda1 rw


After creating snapshot:

15 20 0:15 / /sys rw,nosuid,nodev,noexec,relatime - sysfs sysfs rw
16 20 0:3 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
17 20 0:5 / /dev rw,relatime - devtmpfs udev
rw,size=241692k,nr_inodes=60423,mode=755
18 17 0:12 / /dev/pts rw,nosuid,noexec,relatime - devpts devpts
rw,gid=5,mode=620,ptmxmode=000
19 20 0:16 / /run rw,nosuid,noexec,relatime - tmpfs tmpfs
rw,size=50084k,mode=755
20 0 0:17 /@ / rw,relatime - btrfs /dev/dm-2 rw,space_cache
- WTF?!
21 15 0:20 / /sys/fs/cgroup rw,relatime - tmpfs none rw,size=4k,mode=755
22 15 0:21 / /sys/fs/fuse/connections rw,relatime - fusectl none rw
23 15 0:6 / /sys/kernel/debug rw,relatime - debugfs none rw
24 15 0:10 / /sys/kernel/security rw,relatime - securityfs none rw
25 19 0:22 / /run/lock rw,nosuid,nodev,noexec,relatime - tmpfs none
rw,size=5120k
26 19 0:23 / /run/shm rw,nosuid,nodev,relatime - tmpfs none rw
27 19 0:24 / /run/user rw,nosuid,nodev,noexec,relatime - tmpfs none
rw,size=102400k,mode=755
28 15 0:25 / /sys/fs/pstore rw,relatime - pstore none rw
29 20 253:1 / /boot rw,relatime - ext2 /dev/vda1 rw


So it's consistent with what /proc/mounts reports.



 And more important question: it is only the value
 returned by /proc/mount wrongly or also the filesystem
 content is affected ?


I quote my bug report on this:

The information reported in /proc/mounts is certainly bogus, since
still the origin device is being written, the kernel does not actually
mix up the devices for write operations, and such, the phenomenon does
not cause 

Re: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[Goffredo Baroncelli]

I further investigate this issue.

MegaBrutal, reported the following issue: doing a lvm snapshot of the device of 
a
mounted btrfs fs, the new snapshot device name replaces the name of the 
original 
device in the output of /proc/mounts. This confused tools like grub-probe which
report a wrong root device.

It has to be pointed out that instead the link under 
/sys/fs/btrfs/fsid/devices is
correct.


What happens is that *even if the filesystem is mounted*, doing a
btrfs dev scan of a snapshot (of the real volume), the device name of the
filesystem is replaced with the snapshot one.

Anand, with b96de000b, tried to fix it; however further regression appeared
and Chris reverted this commit (see below).

BR
G.Baroncelli

commit b96de000bc8bc9688b3a2abea4332bd57648a49f
Author: Anand Jain anand.j...@oracle.com
Date:   Thu Jul 3 18:22:05 2014 +0800

Btrfs: device_list_add() should not update list when mounted
[...]


commit 0f23ae74f589304bf33233f85737f4fd368549eb
Author: Chris Mason c...@fb.com
Date:   Thu Sep 18 07:49:05 2014 -0700

Revert Btrfs: device_list_add() should not update list when mounted

This reverts commit b96de000bc8bc9688b3a2abea4332bd57648a49f.

This commit is triggering failures to mount by subvolume id in some
configurations.  The main problem is how many different ways this
scanning function is used, both for scanning while mounted and
unmounted.  A proper cleanup is too big for late rcs.

[...]

On 12/02/2014 09:28 AM, MegaBrutal wrote:
 2014-12-02 8:50 GMT+01:00 Goffredo Baroncelli kreij...@inwind.it:
 On 12/02/2014 01:15 AM, MegaBrutal wrote:
 2014-12-02 0:24 GMT+01:00 Robert White rwh...@pobox.com:
 On 12/01/2014 02:10 PM, MegaBrutal wrote:

 Since having duplicate UUIDs on devices is not a problem for me since
 I can tell them apart by LVM names, the discussion is of little
 relevance to my use case. Of course it's interesting and I like to
 read it along, it is not about the actual problem at hand.


 Which is why you use the device= mount option, which would take LVM names
 and which was repeatedly discussed as solving this very problem.

 Once you decide to duplicate the UUIDs with LVM snapshots you take up the
 burden of disambiguating your storage.

 Which is part of why re-reading was suggested as this was covered in some
 depth and _is_ _exactly_ about the problem at hand.

 Nope.

 root@reproduce-1391429:~# cat /proc/cmdline
 BOOT_IMAGE=/vmlinuz-3.18.0-031800rc5-generic
 root=/dev/mapper/vg-rootlv ro
 rootflags=device=/dev/mapper/vg-rootlv,subvol=@

 Observe, device= mount option is added.

 device= options is needed only in a btrfs multi-volume scenario.
 If you have only one disk, this is not needed

 
 I know. I only did this as a demonstration for Robert. He insisted it
 will certainly solve the problem. Well, it doesn't.
 
 

 root@reproduce-1391429:~# ./reproduce-1391429.sh
 #!/bin/sh -v
 lvs
   LV VG   Attr  LSize   Pool Origin Data%  Move Log Copy%  Convert
   rootlv vg   -wi-ao---   1.00g
   swap0  vg   -wi-ao--- 256.00m

 grub-probe --target=device /
 /dev/mapper/vg-rootlv

 grep  /  /proc/mounts
 rootfs / rootfs rw 0 0
 /dev/dm-1 / btrfs rw,relatime,space_cache 0 0

 lvcreate --snapshot --size=128M --name z vg/rootlv
   Logical volume z created

 lvs
   LV VG   Attr  LSize   Pool Origin Data%  Move Log Copy%  Convert
   rootlv vg   owi-aos--   1.00g
   swap0  vg   -wi-ao--- 256.00m
   z  vg   swi-a-s-- 128.00m  rootlv   0.11

 ls -l /dev/vg/
 total 0
 lrwxrwxrwx 1 root root 7 Dec  2 00:12 rootlv - ../dm-1
 lrwxrwxrwx 1 root root 7 Dec  2 00:12 swap0 - ../dm-0
 lrwxrwxrwx 1 root root 7 Dec  2 00:12 z - ../dm-2

 grub-probe --target=device /
 /dev/mapper/vg-z

 grep  /  /proc/mounts
 rootfs / rootfs rw 0 0
 /dev/dm-2 / btrfs rw,relatime,space_cache 0 0

 What /proc/self/mountinfo contains ?
 
 Before creating snapshot:
 
 15 20 0:15 / /sys rw,nosuid,nodev,noexec,relatime - sysfs sysfs rw
 16 20 0:3 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
 17 20 0:5 / /dev rw,relatime - devtmpfs udev
 rw,size=241692k,nr_inodes=60423,mode=755
 18 17 0:12 / /dev/pts rw,nosuid,noexec,relatime - devpts devpts
 rw,gid=5,mode=620,ptmxmode=000
 19 20 0:16 / /run rw,nosuid,noexec,relatime - tmpfs tmpfs
 rw,size=50084k,mode=755
 20 0 0:17 /@ / rw,relatime - btrfs /dev/dm-1 rw,space_cache
 - THIS!
 21 15 0:20 / /sys/fs/cgroup rw,relatime - tmpfs none rw,size=4k,mode=755
 22 15 0:21 / /sys/fs/fuse/connections rw,relatime - fusectl none rw
 23 15 0:6 / /sys/kernel/debug rw,relatime - debugfs none rw
 24 15 0:10 / /sys/kernel/security rw,relatime - securityfs none rw
 25 19 0:22 / /run/lock rw,nosuid,nodev,noexec,relatime - tmpfs none
 rw,size=5120k
 26 19 0:23 / /run/shm rw,nosuid,nodev,relatime - tmpfs none rw
 27 19 0:24 / /run/user rw,nosuid,nodev,noexec,relatime - tmpfs none
 rw,size=102400k,mode=755
 28 15 0:25 / /sys/fs/pstore rw,relatime - pstore none rw
 29 20 253:1 / /boot rw,relatime - ext2 /dev/vda1 rw
 

Re: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[Anand Jain]

On 02/12/2014 19:14, Goffredo Baroncelli wrote:

I further investigate this issue.

MegaBrutal, reported the following issue: doing a lvm snapshot of the device of 
a
mounted btrfs fs, the new snapshot device name replaces the name of the original
device in the output of /proc/mounts. This confused tools like grub-probe which
report a wrong root device.


very good test case indeed thanks.

Actual IO would still go to the original device, until FS is remounted.



It has to be pointed out that instead the link under 
/sys/fs/btrfs/fsid/devices is
correct.


In this context the above sysfs path will be out of sync with the 
reality, its just stale sysfs entry.




What happens is that *even if the filesystem is mounted*, doing a
btrfs dev scan of a snapshot (of the real volume), the device name of the
filesystem is replaced with the snapshot one.


we have some fundamentally wrong stuff. My original patch tried
to fix it. But later discovered that some external entities like
systmed and boot process is using that bug as a feature and we had
to revert the patch.

Fundamentally scsi inquiry serial number is only number which is unique
to the device (including the virtual device, but there could be some
legacy virtual device which didn't follow that strictly, Anyway those
I deem to be device side issue.) Btrfs depends on the combination of
fsid, uuid and devid (and generation number) to identify the unique
device volume, which is weak and easy to go wrong.



Anand, with b96de000b, tried to fix it; however further regression appeared
and Chris reverted this commit (see below).

BR
G.Baroncelli

commit b96de000bc8bc9688b3a2abea4332bd57648a49f
Author: Anand Jain anand.j...@oracle.com
Date:   Thu Jul 3 18:22:05 2014 +0800

 Btrfs: device_list_add() should not update list when mounted
[...]


commit 0f23ae74f589304bf33233f85737f4fd368549eb
Author: Chris Mason c...@fb.com
Date:   Thu Sep 18 07:49:05 2014 -0700

 Revert Btrfs: device_list_add() should not update list when mounted

 This reverts commit b96de000bc8bc9688b3a2abea4332bd57648a49f.

 This commit is triggering failures to mount by subvolume id in some
 configurations.  The main problem is how many different ways this
 scanning function is used, both for scanning while mounted and
 unmounted.  A proper cleanup is too big for late rcs.

[...]

On 12/02/2014 09:28 AM, MegaBrutal wrote:

2014-12-02 8:50 GMT+01:00 Goffredo Baroncelli kreij...@inwind.it:

On 12/02/2014 01:15 AM, MegaBrutal wrote:

2014-12-02 0:24 GMT+01:00 Robert White rwh...@pobox.com:

On 12/01/2014 02:10 PM, MegaBrutal wrote:


Since having duplicate UUIDs on devices is not a problem for me since
I can tell them apart by LVM names, the discussion is of little
relevance to my use case. Of course it's interesting and I like to
read it along, it is not about the actual problem at hand.



Which is why you use the device= mount option, which would take LVM names
and which was repeatedly discussed as solving this very problem.

Once you decide to duplicate the UUIDs with LVM snapshots you take up the
burden of disambiguating your storage.

Which is part of why re-reading was suggested as this was covered in some
depth and _is_ _exactly_ about the problem at hand.


Nope.

root@reproduce-1391429:~# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.18.0-031800rc5-generic
root=/dev/mapper/vg-rootlv ro
rootflags=device=/dev/mapper/vg-rootlv,subvol=@

Observe, device= mount option is added.


device= options is needed only in a btrfs multi-volume scenario.
If you have only one disk, this is not needed



I know. I only did this as a demonstration for Robert. He insisted it
will certainly solve the problem. Well, it doesn't.




root@reproduce-1391429:~# ./reproduce-1391429.sh
#!/bin/sh -v
lvs
   LV VG   Attr  LSize   Pool Origin Data%  Move Log Copy%  Convert
   rootlv vg   -wi-ao---   1.00g
   swap0  vg   -wi-ao--- 256.00m

grub-probe --target=device /
/dev/mapper/vg-rootlv

grep  /  /proc/mounts
rootfs / rootfs rw 0 0
/dev/dm-1 / btrfs rw,relatime,space_cache 0 0

lvcreate --snapshot --size=128M --name z vg/rootlv
   Logical volume z created

lvs
   LV VG   Attr  LSize   Pool Origin Data%  Move Log Copy%  Convert
   rootlv vg   owi-aos--   1.00g
   swap0  vg   -wi-ao--- 256.00m
   z  vg   swi-a-s-- 128.00m  rootlv   0.11

ls -l /dev/vg/
total 0
lrwxrwxrwx 1 root root 7 Dec  2 00:12 rootlv - ../dm-1
lrwxrwxrwx 1 root root 7 Dec  2 00:12 swap0 - ../dm-0
lrwxrwxrwx 1 root root 7 Dec  2 00:12 z - ../dm-2

grub-probe --target=device /
/dev/mapper/vg-z

grep  /  /proc/mounts
rootfs / rootfs rw 0 0
/dev/dm-2 / btrfs rw,relatime,space_cache 0 0


What /proc/self/mountinfo contains ?


Before creating snapshot:

15 20 0:15 / /sys rw,nosuid,nodev,noexec,relatime - sysfs sysfs rw
16 20 0:3 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
17 20 0:5 / /dev rw,relatime - devtmpfs udev
rw,size=241692k,nr_inodes=60423,mode=755
18 17 0:12 / /dev/pts 

Re: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[Austin S Hemmelgarn]

On 2014-12-02 06:54, Anand Jain wrote:




On 02/12/2014 19:14, Goffredo Baroncelli wrote:

I further investigate this issue.

MegaBrutal, reported the following issue: doing a lvm snapshot of the
device of a
mounted btrfs fs, the new snapshot device name replaces the name of
the original
device in the output of /proc/mounts. This confused tools like
grub-probe which
report a wrong root device.


very good test case indeed thanks.

Actual IO would still go to the original device, until FS is remounted.



It has to be pointed out that instead the link under
/sys/fs/btrfs/fsid/devices is
correct.


In this context the above sysfs path will be out of sync with the
reality, its just stale sysfs entry.



What happens is that *even if the filesystem is mounted*, doing a
btrfs dev scan of a snapshot (of the real volume), the device name
of the
filesystem is replaced with the snapshot one.


we have some fundamentally wrong stuff. My original patch tried
to fix it. But later discovered that some external entities like
systmed and boot process is using that bug as a feature and we had
to revert the patch.

Fundamentally scsi inquiry serial number is only number which is unique
to the device (including the virtual device, but there could be some
legacy virtual device which didn't follow that strictly, Anyway those
I deem to be device side issue.) Btrfs depends on the combination of
fsid, uuid and devid (and generation number) to identify the unique
device volume, which is weak and easy to go wrong.



Anand, with b96de000b, tried to fix it; however further regression
appeared
and Chris reverted this commit (see below).

BR
G.Baroncelli

commit b96de000bc8bc9688b3a2abea4332bd57648a49f
Author: Anand Jain anand.j...@oracle.com
Date:   Thu Jul 3 18:22:05 2014 +0800

 Btrfs: device_list_add() should not update list when mounted
[...]


commit 0f23ae74f589304bf33233f85737f4fd368549eb
Author: Chris Mason c...@fb.com
Date:   Thu Sep 18 07:49:05 2014 -0700

 Revert Btrfs: device_list_add() should not update list when
mounted

 This reverts commit b96de000bc8bc9688b3a2abea4332bd57648a49f.

 This commit is triggering failures to mount by subvolume id in some
 configurations.  The main problem is how many different ways this
 scanning function is used, both for scanning while mounted and
 unmounted.  A proper cleanup is too big for late rcs.

[...]

On 12/02/2014 09:28 AM, MegaBrutal wrote:

2014-12-02 8:50 GMT+01:00 Goffredo Baroncelli kreij...@inwind.it:

On 12/02/2014 01:15 AM, MegaBrutal wrote:

2014-12-02 0:24 GMT+01:00 Robert White rwh...@pobox.com:

On 12/01/2014 02:10 PM, MegaBrutal wrote:


Since having duplicate UUIDs on devices is not a problem for me
since
I can tell them apart by LVM names, the discussion is of little
relevance to my use case. Of course it's interesting and I like to
read it along, it is not about the actual problem at hand.



Which is why you use the device= mount option, which would take
LVM names
and which was repeatedly discussed as solving this very problem.

Once you decide to duplicate the UUIDs with LVM snapshots you take
up the
burden of disambiguating your storage.

Which is part of why re-reading was suggested as this was covered
in some
depth and _is_ _exactly_ about the problem at hand.


Nope.

root@reproduce-1391429:~# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.18.0-031800rc5-generic
root=/dev/mapper/vg-rootlv ro
rootflags=device=/dev/mapper/vg-rootlv,subvol=@

Observe, device= mount option is added.


device= options is needed only in a btrfs multi-volume scenario.
If you have only one disk, this is not needed



I know. I only did this as a demonstration for Robert. He insisted it
will certainly solve the problem. Well, it doesn't.




root@reproduce-1391429:~# ./reproduce-1391429.sh
#!/bin/sh -v
lvs
   LV VG   Attr  LSize   Pool Origin Data%  Move Log Copy%
Convert
   rootlv vg   -wi-ao---   1.00g
   swap0  vg   -wi-ao--- 256.00m

grub-probe --target=device /
/dev/mapper/vg-rootlv

grep  /  /proc/mounts
rootfs / rootfs rw 0 0
/dev/dm-1 / btrfs rw,relatime,space_cache 0 0

lvcreate --snapshot --size=128M --name z vg/rootlv
   Logical volume z created

lvs
   LV VG   Attr  LSize   Pool Origin Data%  Move Log Copy%
Convert
   rootlv vg   owi-aos--   1.00g
   swap0  vg   -wi-ao--- 256.00m
   z  vg   swi-a-s-- 128.00m  rootlv   0.11

ls -l /dev/vg/
total 0
lrwxrwxrwx 1 root root 7 Dec  2 00:12 rootlv - ../dm-1
lrwxrwxrwx 1 root root 7 Dec  2 00:12 swap0 - ../dm-0
lrwxrwxrwx 1 root root 7 Dec  2 00:12 z - ../dm-2

grub-probe --target=device /
/dev/mapper/vg-z

grep  /  /proc/mounts
rootfs / rootfs rw 0 0
/dev/dm-2 / btrfs rw,relatime,space_cache 0 0


What /proc/self/mountinfo contains ?


Before creating snapshot:

15 20 0:15 / /sys rw,nosuid,nodev,noexec,relatime - sysfs sysfs rw
16 20 0:3 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
17 20 0:5 / /dev rw,relatime - devtmpfs udev
rw,size=241692k,nr_inodes=60423,mode=755
18 

Re: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[Phillip Susi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/2/2014 7:23 AM, Austin S Hemmelgarn wrote:
 Stupid thought, why don't we just add blacklisting based on device
 path like LVM has for pvscan?

That isn't logic that belongs in the kernel, so that is going down the
path of yanking out the device auto probing from btrfs and instead
writing a mount.btrfs helper that can use policies like blacklisting
to auto locate all of the correct devices and pass them all to the
kernel at mount time.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUfg7lAAoJENRVrw2cjl5RAakIAKLsIKgjzUO8J/PBBDTmcCQh
IvkEMlQ6ME+Zi7xCKM9p+J5Skcu22zj8w2Ip0s/zNo3ydGorajxehUqtU983l5Hd
VklKOuNGZ0wrOtwCH8IkRt9HUvT3I7982jByi2Uk9jxpRbL/BruaJ4NF+Z9HnvHO
cmMNavcKvwOkYpPHPPbeyjNwWALe/WRZZ2cgsKqs/vB2nakxFntUc1UOsnIMfLJ7
dMF0l9GudoIoNaqRUNoxV1/Lh9MxKx0p9mBK6Pc+V+wLulUyOUSQ6OkUTsznCabk
iUyzX9IYiF83hWO3g+1vxR+GCeYNVGvC/Rj8ZkLSt9Tpi7JH0kbXnq6wKedSfE0=
=Lxfb
-END PGP SIGNATURE-
--
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: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[Phillip Susi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/2/2014 6:54 AM, Anand Jain wrote:
 we have some fundamentally wrong stuff. My original patch tried to
 fix it. But later discovered that some external entities like 
 systmed and boot process is using that bug as a feature and we had 
 to revert the patch.

If systemd is depending on the kernel lieing about what device it has
mounted then something is *extremely* broken there and that should be
fixed instead of breaking the kernel.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUfg+BAAoJENRVrw2cjl5REm8H/j2MEbF2yeTsGtOGhszl82rZ
ngSvVfEEPq1D+tpi28+oZnSLYxIKEGudqTciyeb8Z1jCTD065D/T0xpGJZyd6pUG
KGahBpnPvhP5xg4RaoSxSzNcFzPPFfz+EIPyV+l3OlHbyeq0whkKj5OAq15Grz6c
RDWViqRFRE+dC2k70fAt6mlxWs7ChCVs9fPuuWVTFW+lXBoCKUZhnZ5Kc2orsKx6
rVTNTo6LxZQX7m+9WzIy5lqH+WgqxtfEacAlM/6jXWwPe09DDT3z0s3ogf+dfO0D
3/efDv1XJ/LwmbyQrGxiS0LQWoPA+d+MX0Od3XRcaeml3d7k/tZjDsrFOY6anIg=
=Rxh6
-END PGP SIGNATURE-
--
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: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[Phillip Susi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/1/2014 4:45 PM, Konstantin wrote:
 The bug appears also when using mdadm RAID1 - when one of the
 drives is detached from the array then the OS discovers it and
 after a while (not directly, it takes several minutes) it appears
 under /proc/mounts: instead of /dev/md0p1 I see there /dev/sdb1.
 And usually after some hour or so (depending on system workload)
 the PC completely freezes. So discussion about the uniqueness of
 UUIDs or not, a crashing kernel is telling me that there is a
 serious bug.

I'm guessing you are using metadata format 0.9 or 1.0, which put the
metadata at the end of the drive and the filesystem still starts in
sector zero.  1.2 is now the default and would not have this problem
as its metadata is at the start of the disk ( well, 4k from the start
) and the fs starts further down.



-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUfhC6AAoJENRVrw2cjl5RQ2EH/0Z0iCFjOs3e5oGuGqT5Wtlc
rXV8R1EfGSxESK0g6QAe7QIvJu+0CdIgccDp8z3ezfPcm1/YRfBXxXA/Y1Wl4hqw
0wuk3bNqMjUmNwIFjEZCkgOSn4Whuppbh3hOOVGNropr4cwd84GP1Cr2vrzwYnkm
If1I3RTaBhAJRSngkP9X+L5J6zBBjaZLlF4AjC/WP/1bd5vkHpGqnFpRTquCPiNV
9LFWQIB+xYdoRdK2l7huS2jQ5kfw+qLZUQO17dU3fcicwwNk56V4HcLEPg9nx9es
pxJo9BAWmQXDpeMcCL4eFECoeAhn0IXoaXb363mmpq11qyYj73r3FzhNQ+ALzPY=
=U65Z
-END PGP SIGNATURE-
--
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

PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[MegaBrutal]

Hi all,

I've reported the bug I've previously posted about in BTRFS messes up
snapshot LV with origin in the Kernel Bug Tracker.
https://bugzilla.kernel.org/show_bug.cgi?id=89121

Since the other thread went off into theoretical debates about UUIDs
and their generic relation to BTRFS, their everyday use cases, and the
philosophical meaning behind uniqueness of copies and UUIDs; I'd like
to specifically ask you to only post here about the ACTUAL problem at
hand. Don't get me wrong, I find the discussion in the other thread
really interesting, I'm following it, but it is only very remotely
related to the original issue, so please keep it there! If you're
interested to catch up about the actual bug symptoms, please read the
bug report linked above, and (optionally) reproduce the problem
yourself!

A virtual machine image on which I've already reproduced the
conditions can be downloaded here:
http://undead.megabrutal.com/kvm-reproduce-1391429.img.xz
(Download size: 113 MB; Unpacked image size: 2 GB.)

Re-tested with mainline kernel 3.18.0-rc7 just today.


Regards,
MegaBrutal
--
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: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[Robert White]

On 12/01/2014 04:56 AM, MegaBrutal wrote:

Since the other thread went off into theoretical debates about UUIDs
and their generic relation to BTRFS, their everyday use cases, and the
philosophical meaning behind uniqueness of copies and UUIDs; I'd like
to specifically ask you to only post here about the ACTUAL problem at
hand. Don't get me wrong, I find the discussion in the other thread
really interesting, I'm following it, but it is only very remotely
related to the original issue, so please keep it there! If you're
interested to catch up about the actual bug symptoms, please read the
bug report linked above, and (optionally) reproduce the problem
yourself!


That discussion _was_ the actual discussion of the actual problem. A 
problem that is not particularly theoretical, a problem that is common 
to block-level snapshots, and a discussion that contained the actual 
work-arounds.


I suggest a re-read. 8-)

--
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: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[Konstantin]

MegaBrutal schrieb am 01.12.2014 um 13:56:
 Hi all,

 I've reported the bug I've previously posted about in BTRFS messes up
 snapshot LV with origin in the Kernel Bug Tracker.
 https://bugzilla.kernel.org/show_bug.cgi?id=89121
Hi MegaBrutal. If I understand your report correctly, I can give you
another example where this bug is appearing. It is so bad that it leads
to freezing the system and I'm quite sure it's the same thing. I was
thinking about filing a bug but didn't have the time for that yet. Maybe
you could add this case to your bug report as well.

The bug appears also when using mdadm RAID1 - when one of the drives is
detached from the array then the OS discovers it and after a while (not
directly, it takes several minutes) it appears under /proc/mounts:
instead of /dev/md0p1 I see there /dev/sdb1. And usually after some hour
or so (depending on system workload) the PC completely freezes. So
discussion about the uniqueness of UUIDs or not, a crashing kernel is
telling me that there is a serious bug.

While in my case detaching was intentional, there are several real
possibilities when a RAID1 disk can get detached and currently this
leads to crashing the server when using BTRFS. That not what is intended
when using RAID ;-).

In my case I wanted to do something which was working perfectly all the
years before with all other file systems - checking the file system of
the root disk while the server is running. The procedure is simple:

1. detach one of the disks
2. do fsck on the disk device
3. mdadm --zero-superblock on the device so it gets completely rewritten
4. mdadm --add it to the array

There were some surprises with BTRFS - if 2. is not done directly after
1. btrfsck refuses to check the disk as it is reported to be mounted by
/proc/mounts. And while 2. or even after finishing it the system was
freezing. If I got to get to 4. fast enough everything was OK, but
again, that's not what I expect from a good operating system. Any
objections?

Konstantin

--
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: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[MegaBrutal]

2014-12-01 18:27 GMT+01:00 Robert White rwh...@pobox.com:
 On 12/01/2014 04:56 AM, MegaBrutal wrote:

 Since the other thread went off into theoretical debates about UUIDs
 and their generic relation to BTRFS, their everyday use cases, and the
 philosophical meaning behind uniqueness of copies and UUIDs; I'd like
 to specifically ask you to only post here about the ACTUAL problem at
 hand. Don't get me wrong, I find the discussion in the other thread
 really interesting, I'm following it, but it is only very remotely
 related to the original issue, so please keep it there! If you're
 interested to catch up about the actual bug symptoms, please read the
 bug report linked above, and (optionally) reproduce the problem
 yourself!


 That discussion _was_ the actual discussion of the actual problem. A problem
 that is not particularly theoretical, a problem that is common to
 block-level snapshots, and a discussion that contained the actual
 work-arounds.

 I suggest a re-read. 8-)


The majority of the discussion was about how the kernel should react
UPON mounting a file system when more than one device of the same UUID
exist on the system. While it is a very legit problem worth to discuss
and mitigate, this is not the same situation as how the kernel behaves
when an identical device appears WHILE the file system is being
mounted.

Actually, I would not identify devices by UUIDs when I know that
duplicates could exist due to snapshots, therefore I mount devices by
LVM paths. And when a file system is already mounted with all its
devices, that is a clear situation: all devices are open and locked by
the kernel, any mixup at that point is an error. What is the case with
multiple-device file systems? Supply all their devices with device=
mount options. Just don't identify devices by UUIDs when you know
there could be duplicates. Use UUIDs when you don't use LVM.
Identifying file systems by UUIDs were invented because classic
/dev/sdXX device names might change. But LVM names don't change. They
only change when you intentionally change them e.g. with lvrename.

Since having duplicate UUIDs on devices is not a problem for me since
I can tell them apart by LVM names, the discussion is of little
relevance to my use case. Of course it's interesting and I like to
read it along, it is not about the actual problem at hand.
--
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: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[Robert White]

On 12/01/2014 02:10 PM, MegaBrutal wrote:

Since having duplicate UUIDs on devices is not a problem for me since
I can tell them apart by LVM names, the discussion is of little
relevance to my use case. Of course it's interesting and I like to
read it along, it is not about the actual problem at hand.



Which is why you use the device= mount option, which would take LVM 
names and which was repeatedly discussed as solving this very problem.


Once you decide to duplicate the UUIDs with LVM snapshots you take up 
the burden of disambiguating your storage.


Which is part of why re-reading was suggested as this was covered in 
some depth and _is_ _exactly_ about the problem at hand.

--
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: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[MegaBrutal]

2014-12-02 0:24 GMT+01:00 Robert White rwh...@pobox.com:
 On 12/01/2014 02:10 PM, MegaBrutal wrote:

 Since having duplicate UUIDs on devices is not a problem for me since
 I can tell them apart by LVM names, the discussion is of little
 relevance to my use case. Of course it's interesting and I like to
 read it along, it is not about the actual problem at hand.


 Which is why you use the device= mount option, which would take LVM names
 and which was repeatedly discussed as solving this very problem.

 Once you decide to duplicate the UUIDs with LVM snapshots you take up the
 burden of disambiguating your storage.

 Which is part of why re-reading was suggested as this was covered in some
 depth and _is_ _exactly_ about the problem at hand.

Nope.

root@reproduce-1391429:~# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.18.0-031800rc5-generic
root=/dev/mapper/vg-rootlv ro
rootflags=device=/dev/mapper/vg-rootlv,subvol=@

Observe, device= mount option is added.


root@reproduce-1391429:~# ./reproduce-1391429.sh
#!/bin/sh -v
lvs
  LV VG   Attr  LSize   Pool Origin Data%  Move Log Copy%  Convert
  rootlv vg   -wi-ao---   1.00g
  swap0  vg   -wi-ao--- 256.00m

grub-probe --target=device /
/dev/mapper/vg-rootlv

grep  /  /proc/mounts
rootfs / rootfs rw 0 0
/dev/dm-1 / btrfs rw,relatime,space_cache 0 0

lvcreate --snapshot --size=128M --name z vg/rootlv
  Logical volume z created

lvs
  LV VG   Attr  LSize   Pool Origin Data%  Move Log Copy%  Convert
  rootlv vg   owi-aos--   1.00g
  swap0  vg   -wi-ao--- 256.00m
  z  vg   swi-a-s-- 128.00m  rootlv   0.11

ls -l /dev/vg/
total 0
lrwxrwxrwx 1 root root 7 Dec  2 00:12 rootlv - ../dm-1
lrwxrwxrwx 1 root root 7 Dec  2 00:12 swap0 - ../dm-0
lrwxrwxrwx 1 root root 7 Dec  2 00:12 z - ../dm-2

grub-probe --target=device /
/dev/mapper/vg-z

grep  /  /proc/mounts
rootfs / rootfs rw 0 0
/dev/dm-2 / btrfs rw,relatime,space_cache 0 0

lvremove --force vg/z
  Logical volume z successfully removed

grub-probe --target=device /
/dev/mapper/vg-rootlv

grep  /  /proc/mounts
rootfs / rootfs rw 0 0
/dev/dm-1 / btrfs rw,relatime,space_cache 0 0


Problem still reproduces.
--
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: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[MegaBrutal]

2014-12-01 22:45 GMT+01:00 Konstantin newsbox1...@web.de:

 MegaBrutal schrieb am 01.12.2014 um 13:56:
 Hi all,

 I've reported the bug I've previously posted about in BTRFS messes up
 snapshot LV with origin in the Kernel Bug Tracker.
 https://bugzilla.kernel.org/show_bug.cgi?id=89121
 Hi MegaBrutal. If I understand your report correctly, I can give you
 another example where this bug is appearing. It is so bad that it leads
 to freezing the system and I'm quite sure it's the same thing. I was
 thinking about filing a bug but didn't have the time for that yet. Maybe
 you could add this case to your bug report as well.

 The bug appears also when using mdadm RAID1 - when one of the drives is
 detached from the array then the OS discovers it and after a while (not
 directly, it takes several minutes) it appears under /proc/mounts:
 instead of /dev/md0p1 I see there /dev/sdb1. And usually after some hour
 or so (depending on system workload) the PC completely freezes. So
 discussion about the uniqueness of UUIDs or not, a crashing kernel is
 telling me that there is a serious bug.


Hmm, I also suspect our symptoms have the same root cause. It seems
the same thing happens: the BTRFS module notices another device with
the same file system and starts to report it as the root device. It
seems like it has no idea that it's part of a RAID configuration or
anything.
--
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: PROBLEM: #89121 BTRFS mixes up mounted devices with their snapshots

[Goffredo Baroncelli]

On 12/02/2014 01:15 AM, MegaBrutal wrote:
 2014-12-02 0:24 GMT+01:00 Robert White rwh...@pobox.com:
 On 12/01/2014 02:10 PM, MegaBrutal wrote:

 Since having duplicate UUIDs on devices is not a problem for me since
 I can tell them apart by LVM names, the discussion is of little
 relevance to my use case. Of course it's interesting and I like to
 read it along, it is not about the actual problem at hand.


 Which is why you use the device= mount option, which would take LVM names
 and which was repeatedly discussed as solving this very problem.

 Once you decide to duplicate the UUIDs with LVM snapshots you take up the
 burden of disambiguating your storage.

 Which is part of why re-reading was suggested as this was covered in some
 depth and _is_ _exactly_ about the problem at hand.
 
 Nope.
 
 root@reproduce-1391429:~# cat /proc/cmdline
 BOOT_IMAGE=/vmlinuz-3.18.0-031800rc5-generic
 root=/dev/mapper/vg-rootlv ro
 rootflags=device=/dev/mapper/vg-rootlv,subvol=@
 
 Observe, device= mount option is added.

device= options is needed only in a btrfs multi-volume scenario.
If you have only one disk, this is not needed

 
 
 root@reproduce-1391429:~# ./reproduce-1391429.sh
 #!/bin/sh -v
 lvs
   LV VG   Attr  LSize   Pool Origin Data%  Move Log Copy%  Convert
   rootlv vg   -wi-ao---   1.00g
   swap0  vg   -wi-ao--- 256.00m
 
 grub-probe --target=device /
 /dev/mapper/vg-rootlv
 
 grep  /  /proc/mounts
 rootfs / rootfs rw 0 0
 /dev/dm-1 / btrfs rw,relatime,space_cache 0 0
 
 lvcreate --snapshot --size=128M --name z vg/rootlv
   Logical volume z created
 
 lvs
   LV VG   Attr  LSize   Pool Origin Data%  Move Log Copy%  Convert
   rootlv vg   owi-aos--   1.00g
   swap0  vg   -wi-ao--- 256.00m
   z  vg   swi-a-s-- 128.00m  rootlv   0.11
 
 ls -l /dev/vg/
 total 0
 lrwxrwxrwx 1 root root 7 Dec  2 00:12 rootlv - ../dm-1
 lrwxrwxrwx 1 root root 7 Dec  2 00:12 swap0 - ../dm-0
 lrwxrwxrwx 1 root root 7 Dec  2 00:12 z - ../dm-2
 
 grub-probe --target=device /
 /dev/mapper/vg-z

 grep  /  /proc/mounts
 rootfs / rootfs rw 0 0
 /dev/dm-2 / btrfs rw,relatime,space_cache 0 0

What /proc/self/mountinfo contains ?

And more important question: it is only the value
returned by /proc/mount wrongly or also the filesystem
content is affected ?

 
 lvremove --force vg/z
   Logical volume z successfully removed
 
 grub-probe --target=device /
 /dev/mapper/vg-rootlv
 
 grep  /  /proc/mounts
 rootfs / rootfs rw 0 0
 /dev/dm-1 / btrfs rw,relatime,space_cache 0 0
 
 
 Problem still reproduces.
 --
 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
 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5
--
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

[PATCH] btrfs-progs: fix return value problem for btrfs sub show

[Gui Hecheng]

If you exec:
# btrfs sub show dir  == non-subvolume dir
The cmd print error messages as expected, but returns 0.
By convetion, it should return non-zero and we should explicitly
set it before it goto out.

With other pieces adopted:
1) removed a unnecessary return value set -EINVAL
2) fixed another code branch which may return 0 upon error.
3) with 2) applied, the ret = 0 follows can be removed

Signed-off-by: Gui Hecheng guihc.f...@cn.fujitsu.com
---
 cmds-subvolume.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/cmds-subvolume.c b/cmds-subvolume.c
index fa58a24..53eec46 100644
--- a/cmds-subvolume.c
+++ b/cmds-subvolume.c
@@ -906,6 +906,7 @@ static int cmd_subvol_show(int argc, char **argv)
}
if (!ret) {
fprintf(stderr, ERROR: '%s' is not a subvolume\n, fullpath);
+   ret = 1;
goto out;
}
 
@@ -919,7 +920,6 @@ static int cmd_subvol_show(int argc, char **argv)
fprintf(stderr,
ERROR: %s doesn't belong to btrfs mount point\n,
fullpath);
-   ret = -EINVAL;
goto out;
}
ret = 1;
@@ -958,13 +958,13 @@ static int cmd_subvol_show(int argc, char **argv)
memset(get_ri, 0, sizeof(get_ri));
get_ri.root_id = sv_id;
 
-   if (btrfs_get_subvol(mntfd, get_ri)) {
+   ret = btrfs_get_subvol(mntfd, get_ri);
+   if (ret) {
fprintf(stderr, ERROR: can't find '%s'\n,
svpath);
goto out;
}
 
-   ret = 0;
/* print the info */
printf(%s\n, fullpath);
printf(\tName: \t\t\t%s\n, get_ri.name);
-- 
1.8.1.4

--
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: btrfs check --repair couldn't solve problem with btrfs partition

[Qu Wenruo]

Hi!

Several times I try repair my btrfs partition with follow commands:
[root@localhost ~]# umount /home

root@localhost ~]# btrfs check --repair /dev/sdb1
enabling repair mode
Fixed 0 roots.
Checking filesystem on /dev/sdb1
UUID: 82df2d84-bf54-46cb-84ba-c88e93677948
checking extents
checking free space cache
cache and super generation don't match, space cache will be invalidated
checking fs roots
root 5 inode 14121739 errors 2000, link count wrong
unresolved ref dir 12843363 index 36917 namelen 11 name Preferences
filetype 0 errors 3, no dir item, no dir index
root 5 inode 14121759 errors 2000, link count wrong
unresolved ref dir 139955 index 340700 namelen 18 name
session_state.xspf filetype 0 errors 3, no dir item, no dir index
found 2897923331138 bytes used err is 1

The problem seems not hard to repair in btrfs-progs.

But I'm also curious about why this happens.
Is there any ungraceful shutdown or things like that?

Also, would you mind sending us the btrfs-image dump?
btrfs-debug-tree output would also help, although it may be bigger than
output of btrfs-image.

Thanks,
Qu

total csum bytes: 3100962412
total tree bytes: 4638130176
total fs tree bytes: 950992896
total extent tree bytes: 142475264
btree space waste bytes: 608962027
file data blocks allocated: 33183423946752
  referenced 3177308782592

Btrfs v3.17


# rpm -q btrfs-progs
btrfs-progs-3.17-1.fc21.x86_64


And every time I see this messages.



--
Best Regards,
Mike Gavrilov.
--
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





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

btrfs check --repair couldn't solve problem with btrfs partition

[Михаил Гаврилов]

Hi!

Several times I try repair my btrfs partition with follow commands:
[root@localhost ~]# umount /home

root@localhost ~]# btrfs check --repair /dev/sdb1
enabling repair mode
Fixed 0 roots.
Checking filesystem on /dev/sdb1
UUID: 82df2d84-bf54-46cb-84ba-c88e93677948
checking extents
checking free space cache
cache and super generation don't match, space cache will be invalidated
checking fs roots
root 5 inode 14121739 errors 2000, link count wrong
unresolved ref dir 12843363 index 36917 namelen 11 name Preferences
filetype 0 errors 3, no dir item, no dir index
root 5 inode 14121759 errors 2000, link count wrong
unresolved ref dir 139955 index 340700 namelen 18 name
session_state.xspf filetype 0 errors 3, no dir item, no dir index
found 2897923331138 bytes used err is 1
total csum bytes: 3100962412
total tree bytes: 4638130176
total fs tree bytes: 950992896
total extent tree bytes: 142475264
btree space waste bytes: 608962027
file data blocks allocated: 33183423946752
 referenced 3177308782592

Btrfs v3.17


# rpm -q btrfs-progs
btrfs-progs-3.17-1.fc21.x86_64


And every time I see this messages.



--
Best Regards,
Mike Gavrilov.
--
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

Problem with btrfs send/receive

[Felix Blanke]

Hi everyone,

I was trying the new send/receive feature today but can't make it work.

These are the commands I was using:

btrfs subvol snap -r /mnt/data1/@downloads/ /mnt/data1/snapshots/testsnap
btrfs send /mnt/data1/snapshots/testsnap | btrfs receive
/mnt/data1/snapshots/testreceive/

This command never finishes. A 'ls /mnt/data1/snapshots/testreceive/ '
never finishes too. After killing the send/receive process one can see
that the target subvolume was created but is empty.


Sending the snapshot to a file and use this for receiving does work.
What am I missing?


Kind regards,
Felix
--
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: Problem with btrfs send/receive

[Stefan Behrens]

On Thu, 23 May 2013 13:51:59 +0200, Felix Blanke wrote:
 Hi everyone,
 
 I was trying the new send/receive feature today but can't make it work.
 
 These are the commands I was using:
 
 btrfs subvol snap -r /mnt/data1/@downloads/ /mnt/data1/snapshots/testsnap
 btrfs send /mnt/data1/snapshots/testsnap | btrfs receive
 /mnt/data1/snapshots/testreceive/
 
 This command never finishes. A 'ls /mnt/data1/snapshots/testreceive/ '
 never finishes too. After killing the send/receive process one can see
 that the target subvolume was created but is empty.
 
 
 Sending the snapshot to a file and use this for receiving does work.
 What am I missing?
 

That's a known design flaw in the btrfs send code.
'btrfs send /subvol | sleep 666'
is an easier way to block the system. But it's interruptable if you
terminate the sleep task in this case.

btrfs send blocks on the pipe while being in the kernel, the call chain
is like this:
btrfs_ioctl_send - send_subvol - full_send_tree - changed_cb -
send_cmd - write_buf - vfs_write - pipe_write - pipe_wait

And full_send_tree() has called btrfs_join_transaction() before, thus
the whole file system and afterwards the system is blocked.

You can avoid it if you receive to a different filesystem or if you
redirect the output of btrfs send into a file. In general, the output of
btrfs send must never be blocked or you are lost.

--
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: Problem with btrfs send/receive

[Felix Blanke]

Hi,

thanks for pointing it out. You are right: Sending the snapshot to a
different btrfs fixes the problem. Interesting :) It's not what you
would except, but for my purposes it's ok, because in the end I'll
send it to a different btrfs.

Felix

On Thu, May 23, 2013 at 2:22 PM, Stefan Behrens
sbehr...@giantdisaster.de wrote:
 On Thu, 23 May 2013 13:51:59 +0200, Felix Blanke wrote:
 Hi everyone,

 I was trying the new send/receive feature today but can't make it work.

 These are the commands I was using:

 btrfs subvol snap -r /mnt/data1/@downloads/ /mnt/data1/snapshots/testsnap
 btrfs send /mnt/data1/snapshots/testsnap | btrfs receive
 /mnt/data1/snapshots/testreceive/

 This command never finishes. A 'ls /mnt/data1/snapshots/testreceive/ '
 never finishes too. After killing the send/receive process one can see
 that the target subvolume was created but is empty.


 Sending the snapshot to a file and use this for receiving does work.
 What am I missing?


 That's a known design flaw in the btrfs send code.
 'btrfs send /subvol | sleep 666'
 is an easier way to block the system. But it's interruptable if you
 terminate the sleep task in this case.

 btrfs send blocks on the pipe while being in the kernel, the call chain
 is like this:
 btrfs_ioctl_send - send_subvol - full_send_tree - changed_cb -
 send_cmd - write_buf - vfs_write - pipe_write - pipe_wait

 And full_send_tree() has called btrfs_join_transaction() before, thus
 the whole file system and afterwards the system is blocked.

 You can avoid it if you receive to a different filesystem or if you
 redirect the output of btrfs send into a file. In general, the output of
 btrfs send must never be blocked or you are lost.

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