Problems with btrfs

Problems with btrfs

[David C. Partridge]

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

I'm running Ubuntu 16.04.  I rebooted my server today as it wasn't
responding.

When I rebooted the root FS was read only.

I booted a live Ubuntu CD and checked the drive with the results shown in
attachment btrfs-check.log.

The error was still there after completing the btrfs check --repair :( And
when I deleted some old subvolumes from there after that the filesystem went
read-only with a bunch errors in dmesg which are in the attached file
btrfs-dmesg-errs.log.

Of course my last backup was longer ago than I like to think about. Though I
could restore back to about 8 months ago, I'd very much prefer not to ...

On my bootable CD the Kernel is 4.18.3 and btrfs-progs is 4.7.3-1

HELP!!!

If do have enough space to copy stuff off the root volume but I think I'll
need hand holding through the recovery process.

The volume has sub-volumes called @ and @home which are mounted as / and
/home respectively. 

Thanks
David



[-- Attachment #2: btrfs-check.log --]
[-- Type: application/octet-stream, Size: 1548 bytes --]

root@ubuntu:/home/amonra# btrfs check --repair /dev/mapper/Charon--vg-root
enabling repair mode
Checking filesystem on /dev/mapper/Charon--vg-root
UUID: a0a6c5a6-061f-4c86-bc14-7f9abf3cb57e
checking extents
owner ref check failed [224304857088 16384]
repair deleting extent record: key 224304857088 168 16384
adding new tree backref on start 224304857088 len 16384 parent 140827475968 root 140827475968
repaired damaged extent references
Fixed 0 roots.
checking free space cache
cache and super generation don't match, space cache will be invalidated
checking fs roots
checking csums
checking root refs
found 26552459274 bytes used err is 0
total csum bytes: 23801264
total tree bytes: 2076557312
total fs tree bytes: 1966374912
total extent tree bytes: 77332480
btree space waste bytes: 570994311
file data blocks allocated: 192698544128
 referenced 132293222400
root@ubuntu:/home/amonra# btrfs check /dev/mapper/Charon--vg-root
Checking filesystem on /dev/mapper/Charon--vg-root
UUID: a0a6c5a6-061f-4c86-bc14-7f9abf3cb57e
checking extents
owner ref check failed [224304857088 16384]
checking free space cache
cache and super generation don't match, space cache will be invalidated
checking fs roots
checking csums
checking root refs
found 26552455179 bytes used err is 0
total csum bytes: 23801264
total tree bytes: 2076573696
total fs tree bytes: 1966374912
total extent tree bytes: 77348864
btree space waste bytes: 571010485
file data blocks allocated: 192698544128
 referenced 132293222400
root@ubuntu

[-- Attachment #3: btrfs-dmesg-errs.log --]
[-- Type: application/octet-stream, Size: 3433 bytes --]

[ 3157.354150] BTRFS error (device dm-0): unable to find ref byte nr 259932127232 parent 0 root 257  owner 4401121 offset 0
[ 3157.354160] ------------[ cut here ]------------
[ 3157.354226] WARNING: CPU: 1 PID: 6221 at /home/kernel/COD/linux/fs/btrfs/extent-tree.c:6951 __btrfs_free_extent.isra.71+0x995/0xca0 [btrfs]
[ 3157.354229] BTRFS: Transaction aborted (error -2)
[ 3157.354231] Modules linked in: bnep gpio_ich arc4 ath9k ath9k_common ath9k_hw snd_hda_codec_realtek ath snd_hda_codec_generic mac80211 snd_hda_intel btusb snd_hda_codec btrtl snd_hda_core btbcm btintel cfg80211 snd_hwdep bluetooth snd_pcm input_leds snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq coretemp snd_seq_device snd_timer serio_raw ib_iser snd lpc_ich rdma_cm iw_cm soundcore ib_cm mac_hid shpchp ib_core nfsd configfs iscsi_tcp libiscsi_tcp auth_rpcgss libiscsi nfs_acl scsi_transport_iscsi lockd grace sunrpc parport_pc ppdev lp parport autofs4 isofs nls_iso8859_1 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear dm_mirror dm_region_hash dm_log overlay uas usb_storage hid_generic usbhid hid pata_acpi i915
[ 3157.354381]  video i2c_algo_bit drm_kms_helper psmouse syscopyarea r8169 sysfillrect mii sysimgblt fb_sys_fops ahci drm aacraid libahci pata_jmicron fjes
[ 3157.354419] CPU: 1 PID: 6221 Comm: btrfs-cleaner Tainted: G        W       4.8.13-040813-generic #201612081531
[ 3157.354422] Hardware name: ZOTAC ATOM D525/NM10, BIOS 080016  12/22/2010
[ 3157.354427]  0000000000000286 000000007dca1675 ffff8a18ec897a98 ffffffff97a12d12
[ 3157.354438]  ffff8a18ec897ae8 0000000000000000 ffff8a18ec897ad8 ffffffff97682d9b
[ 3157.354448]  00001b27004327e1 0000003c85298000 00000000fffffffe ffff8a1864c858c0
[ 3157.354457] Call Trace:
[ 3157.354468]  [<ffffffff97a12d12>] dump_stack+0x63/0x81
[ 3157.354477]  [<ffffffff97682d9b>] __warn+0xcb/0xf0
[ 3157.354484]  [<ffffffff97682e1f>] warn_slowpath_fmt+0x5f/0x80
[ 3157.354540]  [<ffffffffc03f9ba5>] __btrfs_free_extent.isra.71+0x995/0xca0 [btrfs]
[ 3157.354601]  [<ffffffffc03fdd3e>] __btrfs_run_delayed_refs+0x59e/0x1280 [btrfs]
[ 3157.354610]  [<ffffffff97a3cfdf>] ? __percpu_counter_add+0x4f/0x60
[ 3157.354666]  [<ffffffffc0401aef>] btrfs_run_delayed_refs+0x9f/0x2c0 [btrfs]
[ 3157.354718]  [<ffffffffc03ff827>] ? walk_up_tree+0xe7/0x1f0 [btrfs]
[ 3157.354780]  [<ffffffffc04171ba>] btrfs_should_end_transaction+0x5a/0x60 [btrfs]
[ 3157.354833]  [<ffffffffc04000b5>] btrfs_drop_snapshot+0x3e5/0x850 [btrfs]
[ 3157.354843]  [<ffffffff97e7e648>] ? __schedule+0x308/0x770
[ 3157.354903]  [<ffffffffc0418534>] btrfs_clean_one_deleted_snapshot+0xb4/0x100 [btrfs]
[ 3157.354957]  [<ffffffffc040efbd>] cleaner_kthread+0x15d/0x1c0 [btrfs]
[ 3157.355011]  [<ffffffffc040ee60>] ? btrfs_destroy_pinned_extent+0x130/0x130 [btrfs]
[ 3157.355034]  [<ffffffff976a3a08>] kthread+0xd8/0xf0
[ 3157.355049]  [<ffffffff97e834df>] ret_from_fork+0x1f/0x40
[ 3157.355065]  [<ffffffff976a3930>] ? kthread_create_on_node+0x1b0/0x1b0
[ 3157.355074] ---[ end trace 51383c1b314f929e ]---
[ 3157.355085] BTRFS: error (device dm-0) in __btrfs_free_extent:6951: errno=-2 No such entry
[ 3157.355102] BTRFS info (device dm-0): forced readonly
[ 3157.355123] BTRFS: error (device dm-0) in btrfs_run_delayed_refs:2960: errno=-2 No such entry
[ 3157.398600] pending csums is 749568
root@ubuntu:/mnt/root# 

Re: Problems with btrfs

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 1620 bytes --]



On 2018年04月28日 02:38, David C. Partridge wrote:
> I'm running Ubuntu 16.04.  I rebooted my server today as it wasn't
> responding.
> 
> When I rebooted the root FS was read only.
> 
> I booted a live Ubuntu CD and checked the drive with the results shown in
> attachment btrfs-check.log.
> 
> The error was still there after completing the btrfs check --repair :( And
> when I deleted some old subvolumes from there after that the filesystem went
> read-only with a bunch errors in dmesg which are in the attached file
> btrfs-dmesg-errs.log.
> 
> Of course my last backup was longer ago than I like to think about. Though I
> could restore back to about 8 months ago, I'd very much prefer not to ...
> 
> On my bootable CD the Kernel is 4.18.3 and btrfs-progs is 4.7.3-1

Hello time traveler. :)
Or it's just 4.16.3.

Btrfs-progs is a little old, and it is not recommended to execute btrfs
check --repair until you know that the problem is.

Fortunately it doesn't cause further damage, although it doesn't fix it
neither.

The offending tree block is 224304857088, please dump the following info
(using latest btrfs-progs if possible)

# btrfs inspect dump-tree -b 224304857088 /dev/mapper/Charon--vg-root
# btrfs inpsect dump-tree /dev/mapper/Charon--vg-root | grep -C 20

Thanks,
Qu

> 
> HELP!!!
> 
> If do have enough space to copy stuff off the root volume but I think I'll
> need hand holding through the recovery process.
> 
> The volume has sub-volumes called @ and @home which are mounted as / and
> /home respectively. 
> 
> Thanks
> David
> 
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Problems with btrfs

[Chris Murphy]

On Fri, Apr 27, 2018 at 6:20 PM, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>
>
> On 2018年04月28日 02:38, David C. Partridge wrote:
>> I'm running Ubuntu 16.04.  I rebooted my server today as it wasn't
>> responding.
>>
>> When I rebooted the root FS was read only.
>>
>> I booted a live Ubuntu CD and checked the drive with the results shown in
>> attachment btrfs-check.log.
>>
>> The error was still there after completing the btrfs check --repair :( And
>> when I deleted some old subvolumes from there after that the filesystem went
>> read-only with a bunch errors in dmesg which are in the attached file
>> btrfs-dmesg-errs.log.
>>
>> Of course my last backup was longer ago than I like to think about. Though I
>> could restore back to about 8 months ago, I'd very much prefer not to ...
>>
>> On my bootable CD the Kernel is 4.18.3 and btrfs-progs is 4.7.3-1
>
> Hello time traveler. :)
> Or it's just 4.16.3.

4.8.13 actually according to the dmesg

The problem might have been setup by this problem (and fix in later kernels)
https://patchwork.kernel.org/patch/5449291/

Question if it's an SSD and what the mount options are.



-- 
Chris Murphy

RE: Problems with btrfs

[David C. Partridge]

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

Here's the log you asked for ...

David

-----Original Message-----
From: Qu Wenruo [mailto:quwenruo.btrfs@gmx.com] 
Sent: 28 April 2018 14:54
To: David C. Partridge
Subject: Re: Problems with btrfs



On 2018年04月28日 21:38, David C. Partridge wrote:
> Oh! doing a private build from source a bit beyond my skill level :(  Are there alternatives like climbing in with a disk editor or is there too much to change?

It's possible to only modify that offending tree block.
But I can't ensure the safety, thus I recommend to use btrfs-corrupt-block.
Since it's not convenient for you, then let's go that way.

Please provide the following dump:

# btrfs inspect dump-tree -t chunk <device>

Then I could calculate the offset on-disk for you to do a binary dump and send that tree block back to me to hand patch it.

> 
> I'm prepared to install a newer version of btrfs-progs if that will fix the problem (assuming I can find a suitable package file).
> 
> I'm assuming that I'll likely also need to update the kernel?

Not exactly.
If latest btrfs check gives no error after fix, even old kernel should handle it well without problem.

But as a generic advice, it's recommended to use latest kernel for btrfs if possible.

And currently there is nothing sensitive in the thread (btrfs-inspect.log could contain some filenames, but nothing sensitive right now), so it's better to CC the mail to mail list, just in case some other guy could provide extra help.

(Next mail may be after 8~10 hours, as it's bed time for my timezone)

Thanks,
Qu

> 
> David
> 
> -----Original Message-----
> From: Qu Wenruo [mailto:quwenruo.btrfs@gmx.com]
> Sent: 28 April 2018 14:25
> To: David C. Partridge
> Subject: Re: Problems with btrfs
> 
> 
> 
> On 2018年04月28日 21:14, David C. Partridge wrote:
>> Here's the output from
>>
>> # btrfs inspect dump-tree /dev/mapper/Charon--vg-root | grep -C 20
>> 224304857088
> 
> Located the problem:
> 
> 	item 382 key (224304857088 EXTENT_ITEM 16384) itemoff 14495 itemsize 51
> 		extent refs 1 gen 735989 flags TREE_BLOCK
> 		tree block key (4401028 UNKNOWN.0 0) level 0
>                                 ^^^^^^^^^^^^^^^^^^^
> 		shared block backref parent 140827475968
> 
> It could be fixed by special crafted btrfs-corrupt-block tool to handle it.
> Although this means you need to compile btrfs-progs by yourself with special branch.
> 
> Before patching btrfs-progs, I'd like to double check if other part is correct.
> 
> Please execute the following command:
> # btrfs inspect dump-tree -b 140827475968 /dev/mapper/Charon--vg-root
> 
> If the output is correct, I could start patching btrfs-corrupt-block then.
> But please be aware of that, this could only fix the problem found in extent tree, I'm not 100% sure if there will be other problems, as the btrfs-progs is pretty old.
> 
> Thanks,
> Qu
> 
>>
>> HtH
>> David
>>
> 


[-- Attachment #2: btrfs-dump-chunk.log --]
[-- Type: application/octet-stream, Size: 17979 bytes --]

btrfs-progs v4.7.3
chunk tree
leaf 302570274816 items 68 free space 8933 generation 849190 owner 3
fs uuid a0a6c5a6-061f-4c86-bc14-7f9abf3cb57e
chunk uuid 98c0b1e7-1845-4803-8965-22f0a655353d
	item 0 key (DEV_ITEMS DEV_ITEM 1) itemoff 16185 itemsize 98
		dev item devid 1 total_bytes 78852915200 bytes used 68144857088
		dev uuid 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 1 key (FIRST_CHUNK_TREE CHUNK_ITEM 124046540800) itemoff 16105 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 51577356288
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 2 key (FIRST_CHUNK_TREE CHUNK_ITEM 129415249920) itemoff 16025 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 30236737536
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 3 key (FIRST_CHUNK_TREE CHUNK_ITEM 130488991744) itemoff 15913 itemsize 112
		chunk length 536870912 owner 2 stripe_len 65536
		type METADATA|DUP num_stripes 2
			stripe 0 devid 1 offset 25941770240
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
			stripe 1 devid 1 offset 26478641152
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 4 key (FIRST_CHUNK_TREE CHUNK_ITEM 131025862656) itemoff 15833 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 24868028416
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 5 key (FIRST_CHUNK_TREE CHUNK_ITEM 132099604480) itemoff 15753 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 19499319296
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 6 key (FIRST_CHUNK_TREE CHUNK_ITEM 133173346304) itemoff 15673 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 16278093824
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 7 key (FIRST_CHUNK_TREE CHUNK_ITEM 134247088128) itemoff 15593 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 11848908800
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 8 key (FIRST_CHUNK_TREE CHUNK_ITEM 135320829952) itemoff 15513 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 9701425152
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 9 key (FIRST_CHUNK_TREE CHUNK_ITEM 136394571776) itemoff 15433 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 8627683328
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 10 key (FIRST_CHUNK_TREE CHUNK_ITEM 137468313600) itemoff 15353 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 6480199680
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 11 key (FIRST_CHUNK_TREE CHUNK_ITEM 138542055424) itemoff 15273 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 4332716032
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 12 key (FIRST_CHUNK_TREE CHUNK_ITEM 140689539072) itemoff 15161 itemsize 112
		chunk length 536870912 owner 2 stripe_len 65536
		type METADATA|DUP num_stripes 2
			stripe 0 devid 1 offset 12989759488
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
			stripe 1 devid 1 offset 13526630400
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 13 key (FIRST_CHUNK_TREE CHUNK_ITEM 143373893632) itemoff 15081 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 2148532224
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 14 key (FIRST_CHUNK_TREE CHUNK_ITEM 144447635456) itemoff 15001 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 5406457856
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 15 key (FIRST_CHUNK_TREE CHUNK_ITEM 158406279168) itemoff 14921 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 32384221184
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 16 key (FIRST_CHUNK_TREE CHUNK_ITEM 199376240640) itemoff 14841 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 59093549056
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 17 key (FIRST_CHUNK_TREE CHUNK_ITEM 217663406080) itemoff 14761 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 7553941504
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 18 key (FIRST_CHUNK_TREE CHUNK_ITEM 221958373376) itemoff 14681 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 18425577472
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 19 key (FIRST_CHUNK_TREE CHUNK_ITEM 224105857024) itemoff 14569 itemsize 112
		chunk length 536870912 owner 2 stripe_len 65536
		type METADATA|DUP num_stripes 2
			stripe 0 devid 1 offset 22720544768
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
			stripe 1 devid 1 offset 23257415680
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 20 key (FIRST_CHUNK_TREE CHUNK_ITEM 226790211584) itemoff 14489 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 27015512064
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 21 key (FIRST_CHUNK_TREE CHUNK_ITEM 230011437056) itemoff 14409 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 31310479360
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 22 key (FIRST_CHUNK_TREE CHUNK_ITEM 232158920704) itemoff 14329 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 34531704832
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 23 key (FIRST_CHUNK_TREE CHUNK_ITEM 236453888000) itemoff 14217 itemsize 112
		chunk length 536870912 owner 2 stripe_len 65536
		type METADATA|DUP num_stripes 2
			stripe 0 devid 1 offset 38826672128
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
			stripe 1 devid 1 offset 39363543040
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 24 key (FIRST_CHUNK_TREE CHUNK_ITEM 244506951680) itemoff 14137 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 48490348544
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 25 key (FIRST_CHUNK_TREE CHUNK_ITEM 250949402624) itemoff 14057 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 56946065408
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 26 key (FIRST_CHUNK_TREE CHUNK_ITEM 252023144448) itemoff 13977 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 58019807232
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 27 key (FIRST_CHUNK_TREE CHUNK_ITEM 254170628096) itemoff 13897 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 61241032704
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 28 key (FIRST_CHUNK_TREE CHUNK_ITEM 256318111744) itemoff 13817 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 63388516352
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 29 key (FIRST_CHUNK_TREE CHUNK_ITEM 257391853568) itemoff 13737 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 64462258176
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 30 key (FIRST_CHUNK_TREE CHUNK_ITEM 260613079040) itemoff 13657 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 67683483648
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 31 key (FIRST_CHUNK_TREE CHUNK_ITEM 261686820864) itemoff 13577 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 68757225472
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 32 key (FIRST_CHUNK_TREE CHUNK_ITEM 262760562688) itemoff 13497 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 69830967296
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 33 key (FIRST_CHUNK_TREE CHUNK_ITEM 263834304512) itemoff 13417 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 70904709120
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 34 key (FIRST_CHUNK_TREE CHUNK_ITEM 265981788160) itemoff 13337 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 73052192768
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 35 key (FIRST_CHUNK_TREE CHUNK_ITEM 268129271808) itemoff 13257 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 75199676416
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 36 key (FIRST_CHUNK_TREE CHUNK_ITEM 269203013632) itemoff 13177 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 76273418240
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 37 key (FIRST_CHUNK_TREE CHUNK_ITEM 270276755456) itemoff 13097 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 77347160064
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 38 key (FIRST_CHUNK_TREE CHUNK_ITEM 271350497280) itemoff 13017 itemsize 80
		chunk length 939524096 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 50637832192
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 39 key (FIRST_CHUNK_TREE CHUNK_ITEM 272290021376) itemoff 12937 itemsize 80
		chunk length 432013312 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 78420901888
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 40 key (FIRST_CHUNK_TREE CHUNK_ITEM 272722034688) itemoff 12857 itemsize 80
		chunk length 67108864 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 12922650624
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 41 key (FIRST_CHUNK_TREE CHUNK_ITEM 272789143552) itemoff 12777 itemsize 80
		chunk length 67108864 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 16210984960
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 42 key (FIRST_CHUNK_TREE CHUNK_ITEM 272908156928) itemoff 12697 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 53724839936
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 43 key (FIRST_CHUNK_TREE CHUNK_ITEM 273981898752) itemoff 12617 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 37752930304
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 44 key (FIRST_CHUNK_TREE CHUNK_ITEM 275055640576) itemoff 12537 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 21646802944
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 45 key (FIRST_CHUNK_TREE CHUNK_ITEM 276162936832) itemoff 12457 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 135266304
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 46 key (FIRST_CHUNK_TREE CHUNK_ITEM 277236678656) itemoff 12377 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 3222274048
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 47 key (FIRST_CHUNK_TREE CHUNK_ITEM 279384162304) itemoff 12265 itemsize 112
		chunk length 536870912 owner 2 stripe_len 65536
		type METADATA|DUP num_stripes 2
			stripe 0 devid 1 offset 14063501312
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
			stripe 1 devid 1 offset 14600372224
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 48 key (FIRST_CHUNK_TREE CHUNK_ITEM 279921033216) itemoff 12185 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 15137243136
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 49 key (FIRST_CHUNK_TREE CHUNK_ITEM 281061883904) itemoff 12105 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 17351835648
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 50 key (FIRST_CHUNK_TREE CHUNK_ITEM 282135625728) itemoff 12025 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 20573061120
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 51 key (FIRST_CHUNK_TREE CHUNK_ITEM 283209367552) itemoff 11945 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 23794286592
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 52 key (FIRST_CHUNK_TREE CHUNK_ITEM 284283109376) itemoff 11865 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 28089253888
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 53 key (FIRST_CHUNK_TREE CHUNK_ITEM 286430593024) itemoff 11785 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 33457963008
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 54 key (FIRST_CHUNK_TREE CHUNK_ITEM 287504334848) itemoff 11705 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 35605446656
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 55 key (FIRST_CHUNK_TREE CHUNK_ITEM 288578076672) itemoff 11625 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 36679188480
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 56 key (FIRST_CHUNK_TREE CHUNK_ITEM 289651818496) itemoff 11545 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 39900413952
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 57 key (FIRST_CHUNK_TREE CHUNK_ITEM 290725560320) itemoff 11465 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 40974155776
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 58 key (FIRST_CHUNK_TREE CHUNK_ITEM 291799302144) itemoff 11385 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 42047897600
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 59 key (FIRST_CHUNK_TREE CHUNK_ITEM 292873043968) itemoff 11305 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 43121639424
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 60 key (FIRST_CHUNK_TREE CHUNK_ITEM 293946785792) itemoff 11225 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 44195381248
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 61 key (FIRST_CHUNK_TREE CHUNK_ITEM 295020527616) itemoff 11145 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 45269123072
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 62 key (FIRST_CHUNK_TREE CHUNK_ITEM 296094269440) itemoff 11065 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 46342864896
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 63 key (FIRST_CHUNK_TREE CHUNK_ITEM 297168011264) itemoff 10985 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 47416606720
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 64 key (FIRST_CHUNK_TREE CHUNK_ITEM 298241753088) itemoff 10905 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 49564090368
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 65 key (FIRST_CHUNK_TREE CHUNK_ITEM 299315494912) itemoff 10825 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 52651098112
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 66 key (FIRST_CHUNK_TREE CHUNK_ITEM 301496532992) itemoff 10745 itemsize 80
		chunk length 1073741824 owner 2 stripe_len 65536
		type DATA num_stripes 1
			stripe 0 devid 1 offset 29162995712
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
	item 67 key (FIRST_CHUNK_TREE CHUNK_ITEM 302570274816) itemoff 10633 itemsize 112
		chunk length 33554432 owner 2 stripe_len 65536
		type SYSTEM|DUP num_stripes 2
			stripe 0 devid 1 offset 68157440
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
			stripe 1 devid 1 offset 101711872
			dev uuid: 5e27c2ed-872b-4bcf-946f-d7f9e81e2c32
total bytes 78852915200
bytes used 26553249792
uuid a0a6c5a6-061f-4c86-bc14-7f9abf3cb57e

Re: Problems with btrfs

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 3429 bytes --]



On 2018年04月28日 22:06, David C. Partridge wrote:
> Here's the log you asked for ...
> 
> David

To dump the offending tree block, you could use the following command:

# dd if=/dev/mapper/Charon--vg-root of=copy1.dump bs=1 count=16k
skip=22919544832

# dd if=/dev/mapper/Charon--vg-root of=copy2.dump bs=1 count=16k
skip=23456415744

And attach copy1.img and copy2.img.

Thanks,
Qu

> 
> -----Original Message-----
> From: Qu Wenruo [mailto:quwenruo.btrfs@gmx.com] 
> Sent: 28 April 2018 14:54
> To: David C. Partridge
> Subject: Re: Problems with btrfs
> 
> 
> 
> On 2018年04月28日 21:38, David C. Partridge wrote:
>> Oh! doing a private build from source a bit beyond my skill level :(  Are there alternatives like climbing in with a disk editor or is there too much to change?
> 
> It's possible to only modify that offending tree block.
> But I can't ensure the safety, thus I recommend to use btrfs-corrupt-block.
> Since it's not convenient for you, then let's go that way.
> 
> Please provide the following dump:
> 
> # btrfs inspect dump-tree -t chunk <device>
> 
> Then I could calculate the offset on-disk for you to do a binary dump and send that tree block back to me to hand patch it.
> 
>>
>> I'm prepared to install a newer version of btrfs-progs if that will fix the problem (assuming I can find a suitable package file).
>>
>> I'm assuming that I'll likely also need to update the kernel?
> 
> Not exactly.
> If latest btrfs check gives no error after fix, even old kernel should handle it well without problem.
> 
> But as a generic advice, it's recommended to use latest kernel for btrfs if possible.
> 
> And currently there is nothing sensitive in the thread (btrfs-inspect.log could contain some filenames, but nothing sensitive right now), so it's better to CC the mail to mail list, just in case some other guy could provide extra help.
> 
> (Next mail may be after 8~10 hours, as it's bed time for my timezone)
> 
> Thanks,
> Qu
> 
>>
>> David
>>
>> -----Original Message-----
>> From: Qu Wenruo [mailto:quwenruo.btrfs@gmx.com]
>> Sent: 28 April 2018 14:25
>> To: David C. Partridge
>> Subject: Re: Problems with btrfs
>>
>>
>>
>> On 2018年04月28日 21:14, David C. Partridge wrote:
>>> Here's the output from
>>>
>>> # btrfs inspect dump-tree /dev/mapper/Charon--vg-root | grep -C 20
>>> 224304857088
>>
>> Located the problem:
>>
>> 	item 382 key (224304857088 EXTENT_ITEM 16384) itemoff 14495 itemsize 51
>> 		extent refs 1 gen 735989 flags TREE_BLOCK
>> 		tree block key (4401028 UNKNOWN.0 0) level 0
>>                                 ^^^^^^^^^^^^^^^^^^^
>> 		shared block backref parent 140827475968
>>
>> It could be fixed by special crafted btrfs-corrupt-block tool to handle it.
>> Although this means you need to compile btrfs-progs by yourself with special branch.
>>
>> Before patching btrfs-progs, I'd like to double check if other part is correct.
>>
>> Please execute the following command:
>> # btrfs inspect dump-tree -b 140827475968 /dev/mapper/Charon--vg-root
>>
>> If the output is correct, I could start patching btrfs-corrupt-block then.
>> But please be aware of that, this could only fix the problem found in extent tree, I'm not 100% sure if there will be other problems, as the btrfs-progs is pretty old.
>>
>> Thanks,
>> Qu
>>
>>>
>>> HtH
>>> David
>>>
>>
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

RE: Problems with btrfs

[David C. Partridge]

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

Here are the dumps you requested.

-----Original Message-----
From: Qu Wenruo [mailto:quwenruo.btrfs@gmx.com] 
Sent: 28 April 2018 15:23
To: David C. Partridge; linux-btrfs@vger.kernel.org
Subject: Re: Problems with btrfs



On 2018年04月28日 22:06, David C. Partridge wrote:
> Here's the log you asked for ...
> 
> David

To dump the offending tree block, you could use the following command:

# dd if=/dev/mapper/Charon--vg-root of=copy1.dump bs=1 count=16k
skip=22919544832

# dd if=/dev/mapper/Charon--vg-root of=copy2.dump bs=1 count=16k
skip=23456415744

And attach copy1.img and copy2.img.

Thanks,
Qu

> 
> -----Original Message-----
> From: Qu Wenruo [mailto:quwenruo.btrfs@gmx.com] 
> Sent: 28 April 2018 14:54
> To: David C. Partridge
> Subject: Re: Problems with btrfs
> 
> 
> 
> On 2018年04月28日 21:38, David C. Partridge wrote:
>> Oh! doing a private build from source a bit beyond my skill level :(  Are there alternatives like climbing in with a disk editor or is there too much to change?
> 
> It's possible to only modify that offending tree block.
> But I can't ensure the safety, thus I recommend to use btrfs-corrupt-block.
> Since it's not convenient for you, then let's go that way.
> 
> Please provide the following dump:
> 
> # btrfs inspect dump-tree -t chunk <device>
> 
> Then I could calculate the offset on-disk for you to do a binary dump and send that tree block back to me to hand patch it.
> 
>>
>> I'm prepared to install a newer version of btrfs-progs if that will fix the problem (assuming I can find a suitable package file).
>>
>> I'm assuming that I'll likely also need to update the kernel?
> 
> Not exactly.
> If latest btrfs check gives no error after fix, even old kernel should handle it well without problem.
> 
> But as a generic advice, it's recommended to use latest kernel for btrfs if possible.
> 
> And currently there is nothing sensitive in the thread (btrfs-inspect.log could contain some filenames, but nothing sensitive right now), so it's better to CC the mail to mail list, just in case some other guy could provide extra help.
> 
> (Next mail may be after 8~10 hours, as it's bed time for my timezone)
> 
> Thanks,
> Qu
> 
>>
>> David
>>
>> -----Original Message-----
>> From: Qu Wenruo [mailto:quwenruo.btrfs@gmx.com]
>> Sent: 28 April 2018 14:25
>> To: David C. Partridge
>> Subject: Re: Problems with btrfs
>>
>>
>>
>> On 2018年04月28日 21:14, David C. Partridge wrote:
>>> Here's the output from
>>>
>>> # btrfs inspect dump-tree /dev/mapper/Charon--vg-root | grep -C 20
>>> 224304857088
>>
>> Located the problem:
>>
>> 	item 382 key (224304857088 EXTENT_ITEM 16384) itemoff 14495 itemsize 51
>> 		extent refs 1 gen 735989 flags TREE_BLOCK
>> 		tree block key (4401028 UNKNOWN.0 0) level 0
>>                                 ^^^^^^^^^^^^^^^^^^^
>> 		shared block backref parent 140827475968
>>
>> It could be fixed by special crafted btrfs-corrupt-block tool to handle it.
>> Although this means you need to compile btrfs-progs by yourself with special branch.
>>
>> Before patching btrfs-progs, I'd like to double check if other part is correct.
>>
>> Please execute the following command:
>> # btrfs inspect dump-tree -b 140827475968 /dev/mapper/Charon--vg-root
>>
>> If the output is correct, I could start patching btrfs-corrupt-block then.
>> But please be aware of that, this could only fix the problem found in extent tree, I'm not 100% sure if there will be other problems, as the btrfs-progs is pretty old.
>>
>> Thanks,
>> Qu
>>
>>>
>>> HtH
>>> David
>>>
>>
> 


[-- Attachment #2: copy1.img --]
[-- Type: application/octet-stream, Size: 16384 bytes --]

[-- Attachment #3: copy2.img --]
[-- Type: application/octet-stream, Size: 16384 bytes --]

Re: Problems with btrfs

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 4138 bytes --]



On 2018年04月29日 00:02, David C. Partridge wrote:
> Here are the dumps you requested.

Sorry, I took wrong dump.

The correct dump would be:
# btrfs inspect dump-tree -t extent <dev>

And you still need to do an extra dump for the final offending tree block.

Considering the extra steps and delays, feel free to use btrfs-restore
to recovery your data.

Thanks,
Qu

> 
> -----Original Message-----
> From: Qu Wenruo [mailto:quwenruo.btrfs@gmx.com] 
> Sent: 28 April 2018 15:23
> To: David C. Partridge; linux-btrfs@vger.kernel.org
> Subject: Re: Problems with btrfs
> 
> 
> 
> On 2018年04月28日 22:06, David C. Partridge wrote:
>> Here's the log you asked for ...
>>
>> David
> 
> To dump the offending tree block, you could use the following command:
> 
> # dd if=/dev/mapper/Charon--vg-root of=copy1.dump bs=1 count=16k
> skip=22919544832
> 
> # dd if=/dev/mapper/Charon--vg-root of=copy2.dump bs=1 count=16k
> skip=23456415744
> 
> And attach copy1.img and copy2.img.
> 
> Thanks,
> Qu
> 
>>
>> -----Original Message-----
>> From: Qu Wenruo [mailto:quwenruo.btrfs@gmx.com] 
>> Sent: 28 April 2018 14:54
>> To: David C. Partridge
>> Subject: Re: Problems with btrfs
>>
>>
>>
>> On 2018年04月28日 21:38, David C. Partridge wrote:
>>> Oh! doing a private build from source a bit beyond my skill level :(  Are there alternatives like climbing in with a disk editor or is there too much to change?
>>
>> It's possible to only modify that offending tree block.
>> But I can't ensure the safety, thus I recommend to use btrfs-corrupt-block.
>> Since it's not convenient for you, then let's go that way.
>>
>> Please provide the following dump:
>>
>> # btrfs inspect dump-tree -t chunk <device>
>>
>> Then I could calculate the offset on-disk for you to do a binary dump and send that tree block back to me to hand patch it.
>>
>>>
>>> I'm prepared to install a newer version of btrfs-progs if that will fix the problem (assuming I can find a suitable package file).
>>>
>>> I'm assuming that I'll likely also need to update the kernel?
>>
>> Not exactly.
>> If latest btrfs check gives no error after fix, even old kernel should handle it well without problem.
>>
>> But as a generic advice, it's recommended to use latest kernel for btrfs if possible.
>>
>> And currently there is nothing sensitive in the thread (btrfs-inspect.log could contain some filenames, but nothing sensitive right now), so it's better to CC the mail to mail list, just in case some other guy could provide extra help.
>>
>> (Next mail may be after 8~10 hours, as it's bed time for my timezone)
>>
>> Thanks,
>> Qu
>>
>>>
>>> David
>>>
>>> -----Original Message-----
>>> From: Qu Wenruo [mailto:quwenruo.btrfs@gmx.com]
>>> Sent: 28 April 2018 14:25
>>> To: David C. Partridge
>>> Subject: Re: Problems with btrfs
>>>
>>>
>>>
>>> On 2018年04月28日 21:14, David C. Partridge wrote:
>>>> Here's the output from
>>>>
>>>> # btrfs inspect dump-tree /dev/mapper/Charon--vg-root | grep -C 20
>>>> 224304857088
>>>
>>> Located the problem:
>>>
>>> 	item 382 key (224304857088 EXTENT_ITEM 16384) itemoff 14495 itemsize 51
>>> 		extent refs 1 gen 735989 flags TREE_BLOCK
>>> 		tree block key (4401028 UNKNOWN.0 0) level 0
>>>                                 ^^^^^^^^^^^^^^^^^^^
>>> 		shared block backref parent 140827475968
>>>
>>> It could be fixed by special crafted btrfs-corrupt-block tool to handle it.
>>> Although this means you need to compile btrfs-progs by yourself with special branch.
>>>
>>> Before patching btrfs-progs, I'd like to double check if other part is correct.
>>>
>>> Please execute the following command:
>>> # btrfs inspect dump-tree -b 140827475968 /dev/mapper/Charon--vg-root
>>>
>>> If the output is correct, I could start patching btrfs-corrupt-block then.
>>> But please be aware of that, this could only fix the problem found in extent tree, I'm not 100% sure if there will be other problems, as the btrfs-progs is pretty old.
>>>
>>> Thanks,
>>> Qu
>>>
>>>>
>>>> HtH
>>>> David
>>>>
>>>
>>
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Problems with btrfs

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 4771 bytes --]



On 2018年04月29日 09:55, David C. Partridge wrote:
> Not a problem
> 
> See attached

The final binary dump:

# dd if=<device> of=/tmp/copy1.img bs=1 count=16K skip=25942081536
# dd if=<device> of=/tmp/copy2.img bs=1 count=16K skip=26478952448

Thanks,
Qu

> 
> 
> -----Original Message-----
> From: Qu Wenruo [mailto:quwenruo.btrfs@gmx.com] 
> Sent: 29 April 2018 02:35
> To: David C. Partridge; linux-btrfs@vger.kernel.org
> Subject: Re: Problems with btrfs
> 
> 
> 
> On 2018年04月29日 00:02, David C. Partridge wrote:
>> Here are the dumps you requested.
> 
> Sorry, I took wrong dump.
> 
> The correct dump would be:
> # btrfs inspect dump-tree -t extent <dev>
> 
> And you still need to do an extra dump for the final offending tree block.
> 
> Considering the extra steps and delays, feel free to use btrfs-restore to recovery your data.
> 
> Thanks,
> Qu
> 
>>
>> -----Original Message-----
>> From: Qu Wenruo [mailto:quwenruo.btrfs@gmx.com]
>> Sent: 28 April 2018 15:23
>> To: David C. Partridge; linux-btrfs@vger.kernel.org
>> Subject: Re: Problems with btrfs
>>
>>
>>
>> On 2018年04月28日 22:06, David C. Partridge wrote:
>>> Here's the log you asked for ...
>>>
>>> David
>>
>> To dump the offending tree block, you could use the following command:
>>
>> # dd if=/dev/mapper/Charon--vg-root of=copy1.dump bs=1 count=16k
>> skip=22919544832
>>
>> # dd if=/dev/mapper/Charon--vg-root of=copy2.dump bs=1 count=16k
>> skip=23456415744
>>
>> And attach copy1.img and copy2.img.
>>
>> Thanks,
>> Qu
>>
>>>
>>> -----Original Message-----
>>> From: Qu Wenruo [mailto:quwenruo.btrfs@gmx.com]
>>> Sent: 28 April 2018 14:54
>>> To: David C. Partridge
>>> Subject: Re: Problems with btrfs
>>>
>>>
>>>
>>> On 2018年04月28日 21:38, David C. Partridge wrote:
>>>> Oh! doing a private build from source a bit beyond my skill level :(  Are there alternatives like climbing in with a disk editor or is there too much to change?
>>>
>>> It's possible to only modify that offending tree block.
>>> But I can't ensure the safety, thus I recommend to use btrfs-corrupt-block.
>>> Since it's not convenient for you, then let's go that way.
>>>
>>> Please provide the following dump:
>>>
>>> # btrfs inspect dump-tree -t chunk <device>
>>>
>>> Then I could calculate the offset on-disk for you to do a binary dump and send that tree block back to me to hand patch it.
>>>
>>>>
>>>> I'm prepared to install a newer version of btrfs-progs if that will fix the problem (assuming I can find a suitable package file).
>>>>
>>>> I'm assuming that I'll likely also need to update the kernel?
>>>
>>> Not exactly.
>>> If latest btrfs check gives no error after fix, even old kernel should handle it well without problem.
>>>
>>> But as a generic advice, it's recommended to use latest kernel for btrfs if possible.
>>>
>>> And currently there is nothing sensitive in the thread (btrfs-inspect.log could contain some filenames, but nothing sensitive right now), so it's better to CC the mail to mail list, just in case some other guy could provide extra help.
>>>
>>> (Next mail may be after 8~10 hours, as it's bed time for my timezone)
>>>
>>> Thanks,
>>> Qu
>>>
>>>>
>>>> David
>>>>
>>>> -----Original Message-----
>>>> From: Qu Wenruo [mailto:quwenruo.btrfs@gmx.com]
>>>> Sent: 28 April 2018 14:25
>>>> To: David C. Partridge
>>>> Subject: Re: Problems with btrfs
>>>>
>>>>
>>>>
>>>> On 2018年04月28日 21:14, David C. Partridge wrote:
>>>>> Here's the output from
>>>>>
>>>>> # btrfs inspect dump-tree /dev/mapper/Charon--vg-root | grep -C 20
>>>>> 224304857088
>>>>
>>>> Located the problem:
>>>>
>>>> 	item 382 key (224304857088 EXTENT_ITEM 16384) itemoff 14495 itemsize 51
>>>> 		extent refs 1 gen 735989 flags TREE_BLOCK
>>>> 		tree block key (4401028 UNKNOWN.0 0) level 0
>>>>                                 ^^^^^^^^^^^^^^^^^^^
>>>> 		shared block backref parent 140827475968
>>>>
>>>> It could be fixed by special crafted btrfs-corrupt-block tool to handle it.
>>>> Although this means you need to compile btrfs-progs by yourself with special branch.
>>>>
>>>> Before patching btrfs-progs, I'd like to double check if other part is correct.
>>>>
>>>> Please execute the following command:
>>>> # btrfs inspect dump-tree -b 140827475968 
>>>> /dev/mapper/Charon--vg-root
>>>>
>>>> If the output is correct, I could start patching btrfs-corrupt-block then.
>>>> But please be aware of that, this could only fix the problem found in extent tree, I'm not 100% sure if there will be other problems, as the btrfs-progs is pretty old.
>>>>
>>>> Thanks,
>>>> Qu
>>>>
>>>>>
>>>>> HtH
>>>>> David
>>>>>
>>>>
>>>
>>
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

RE: Problems with btrfs

[David C. Partridge]

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

Here is the result of btrfs check after applying the patch

Dave
-----Original Message-----
From: Qu Wenruo [mailto:quwenruo.btrfs@gmx.com] 
Sent: 29 April 2018 09:36
To: David C. Partridge
Subject: Re: Problems with btrfs

Here is the patched binary tree block.

You could apply them by the following command (copy1 and copy2 are the same).

# dd if=copy1.img of=<device> bs=1 count=16K seek=25942081536 # dd if=copy1.img of=<device> bs=1 count=16K seek=26478952448

And after that, try btrfs check to see if it reports new error.

Thanks,
Qu

On 2018年04月29日 16:24, David C. Partridge wrote:
> Attached as requested
> 
> -----Original Message-----
> From: linux-btrfs-owner@vger.kernel.org 
> [mailto:linux-btrfs-owner@vger.kernel.org] On Behalf Of Qu Wenruo
> Sent: 29 April 2018 03:08
> To: David C. Partridge; linux-btrfs@vger.kernel.org
> Subject: Re: Problems with btrfs
> 
> 
> 
> On 2018年04月29日 09:55, David C. Partridge wrote:
>> Not a problem
>>
>> See attached
> 
> The final binary dump:
> 
> # dd if=<device> of=/tmp/copy1.img bs=1 count=16K skip=25942081536 # 
> dd if=<device> of=/tmp/copy2.img bs=1 count=16K skip=26478952448
> 
> Thanks,
> Qu
> 

[-- Attachment #2: btrfs-check1.log --]
[-- Type: application/octet-stream, Size: 866 bytes --]

root@ubuntu:/home/amonra# btrfs check /dev/mapper/Charon--vg-root
Checking filesystem on /dev/mapper/Charon--vg-root
UUID: a0a6c5a6-061f-4c86-bc14-7f9abf3cb57e
checking extents
owner ref check failed [224304857088 16384]
checking free space cache
Wanted bytes 32768, found 65536 for off 236453888000
Wanted bytes 536870912, found 65536 for off 236453888000
cache appears valid but isn't 236453888000
Wanted bytes 16384, found 557056 for off 279384162304
Wanted bytes 536870912, found 557056 for off 279384162304
cache appears valid but isn't 279384162304
found 26552209419 bytes used err is -22
total csum bytes: 23801264
total tree bytes: 2076573696
total fs tree bytes: 1966374912
total extent tree bytes: 77348864
btree space waste bytes: 571022401
file data blocks allocated: 192698281984
 referenced 132292960256
root@ubuntu:/home/amonra# 

Re: Problems with btrfs

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 1575 bytes --]



On 2018年04月29日 17:20, David C. Partridge wrote:
> Here is the result of btrfs check after applying the patch

Doesn't work as expected.

Did you apply the patched tree block with "seek="?

If so, please dump extent tree again to verify if the modification is
done correct.

# btrfs inspect dump-tree -t extent <device>

Thanks,
Qu

> 
> Dave
> -----Original Message-----
> From: Qu Wenruo [mailto:quwenruo.btrfs@gmx.com] 
> Sent: 29 April 2018 09:36
> To: David C. Partridge
> Subject: Re: Problems with btrfs
> 
> Here is the patched binary tree block.
> 
> You could apply them by the following command (copy1 and copy2 are the same).
> 
> # dd if=copy1.img of=<device> bs=1 count=16K seek=25942081536 # dd if=copy1.img of=<device> bs=1 count=16K seek=26478952448
> 
> And after that, try btrfs check to see if it reports new error.
> 
> Thanks,
> Qu
> 
> On 2018年04月29日 16:24, David C. Partridge wrote:
>> Attached as requested
>>
>> -----Original Message-----
>> From: linux-btrfs-owner@vger.kernel.org 
>> [mailto:linux-btrfs-owner@vger.kernel.org] On Behalf Of Qu Wenruo
>> Sent: 29 April 2018 03:08
>> To: David C. Partridge; linux-btrfs@vger.kernel.org
>> Subject: Re: Problems with btrfs
>>
>>
>>
>> On 2018年04月29日 09:55, David C. Partridge wrote:
>>> Not a problem
>>>
>>> See attached
>>
>> The final binary dump:
>>
>> # dd if=<device> of=/tmp/copy1.img bs=1 count=16K skip=25942081536 # 
>> dd if=<device> of=/tmp/copy2.img bs=1 count=16K skip=26478952448
>>
>> Thanks,
>> Qu
>>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

RE: Problems with btrfs

[David C. Partridge]

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

Yes I did use seek=

I attach the new dump-tree - it seems very short compared to the last one you requested ???

Dave

-----Original Message-----
From: Qu Wenruo [mailto:quwenruo.btrfs@gmx.com] 
Sent: 29 April 2018 10:36
To: David C. Partridge; linux-btrfs@vger.kernel.org
Subject: Re: Problems with btrfs



On 2018年04月29日 17:20, David C. Partridge wrote:
> Here is the result of btrfs check after applying the patch

Doesn't work as expected.

Did you apply the patched tree block with "seek="?

If so, please dump extent tree again to verify if the modification is done correct.

# btrfs inspect dump-tree -t extent <device>

Thanks,
Qu

> 
> Dave
> -----Original Message-----
> From: Qu Wenruo [mailto:quwenruo.btrfs@gmx.com]
> Sent: 29 April 2018 09:36
> To: David C. Partridge
> Subject: Re: Problems with btrfs
> 
> Here is the patched binary tree block.
> 
> You could apply them by the following command (copy1 and copy2 are the same).
> 
> # dd if=copy1.img of=<device> bs=1 count=16K seek=25942081536 # dd 
> if=copy1.img of=<device> bs=1 count=16K seek=26478952448
> 
> And after that, try btrfs check to see if it reports new error.
> 
> Thanks,
> Qu
> 
> On 2018年04月29日 16:24, David C. Partridge wrote:
>> Attached as requested
>>
>> -----Original Message-----
>> From: linux-btrfs-owner@vger.kernel.org 
>> [mailto:linux-btrfs-owner@vger.kernel.org] On Behalf Of Qu Wenruo
>> Sent: 29 April 2018 03:08
>> To: David C. Partridge; linux-btrfs@vger.kernel.org
>> Subject: Re: Problems with btrfs
>>
>>
>>
>> On 2018年04月29日 09:55, David C. Partridge wrote:
>>> Not a problem
>>>
>>> See attached
>>
>> The final binary dump:
>>
>> # dd if=<device> of=/tmp/copy1.img bs=1 count=16K skip=25942081536 # 
>> dd if=<device> of=/tmp/copy2.img bs=1 count=16K skip=26478952448
>>
>> Thanks,
>> Qu
>>


[-- Attachment #2: btrfs-dump-tree1.log --]
[-- Type: application/octet-stream, Size: 7006 bytes --]

btrfs: unknown token 'inpect'
usage: btrfs [--help] [--version] <group> [<group>...] <command> [<args>]

    btrfs subvolume create [-i <qgroupid>] [<dest>/]<name>
        Create a subvolume
    btrfs subvolume delete [options] <subvolume> [<subvolume>...]
        Delete subvolume(s)
    btrfs subvolume list [options] [-G [+|-]value] [-C [+|-]value] [--sort=gen,ogen,rootid,path] <path>
        List subvolumes (and snapshots)
    btrfs subvolume snapshot [-r] [-i <qgroupid>] <source> <dest>|[<dest>/]<name>
        Create a snapshot of the subvolume
    btrfs subvolume get-default <path>
        Get the default subvolume of a filesystem
    btrfs subvolume set-default <subvolid> <path>
        Set the default subvolume of a filesystem
    btrfs subvolume find-new <path> <lastgen>
        List the recently modified files in a filesystem
    btrfs subvolume show <subvol-path>
        Show more information of the subvolume
    btrfs subvolume sync <path> [<subvol-id>...]
        Wait until given subvolume(s) are completely removed from the filesystem.

    btrfs filesystem df [options] <path>
        Show space usage information for a mount point
    btrfs filesystem du [options] <path> [<path>..]
        Summarize disk usage of each file.
    btrfs filesystem show [options] [<path>|<uuid>|<device>|label]
        Show the structure of a filesystem
    btrfs filesystem sync <path>
        Force a sync on a filesystem
    btrfs filesystem defragment [options] <file>|<dir> [<file>|<dir>...]
        Defragment a file or a directory
    btrfs filesystem resize [devid:][+/-]<newsize>[kKmMgGtTpPeE]|[devid:]max <path>
        Resize a filesystem
    btrfs filesystem label [<device>|<mount_point>] [<newlabel>]
        Get or change the label of a filesystem
    btrfs filesystem usage [options] <path> [<path>..]
        Show detailed information about internal filesystem usage .

    btrfs balance start [options] <path>
        Balance chunks across the devices
    btrfs balance pause <path>
        Pause running balance
    btrfs balance cancel <path>
        Cancel running or paused balance
    btrfs balance resume <path>
        Resume interrupted balance
    btrfs balance status [-v] <path>
        Show status of running or paused balance

    btrfs device add [options] <device> [<device>...] <path>
        Add a device to a filesystem
    btrfs device delete <device>|<devid> [<device>|<devid>...] <path>    btrfs device remove <device>|<devid> [<device>|<devid>...] <path>
        Remove a device from a filesystem
    btrfs device scan [(-d|--all-devices)|<device> [<device>...]]
        Scan devices for a btrfs filesystem
    btrfs device ready <device>
        Check device to see if it has all of its devices in cache for mounting
    btrfs device stats [-z] <path>|<device>
        Show current device IO stats.
    btrfs device usage [options] <path> [<path>..]
        Show detailed information about internal allocations in devices.

    btrfs scrub start [-BdqrRf] [-c ioprio_class -n ioprio_classdata] <path>|<device>
        Start a new scrub. If a scrub is already running, the new one fails.
    btrfs scrub cancel <path>|<device>
        Cancel a running scrub
    btrfs scrub resume [-BdqrR] [-c ioprio_class -n ioprio_classdata] <path>|<device>
        Resume previously canceled or interrupted scrub
    btrfs scrub status [-dR] <path>|<device>
        Show status of running or finished scrub

    btrfs check [options] <device>
        Check structural integrity of a filesystem (unmounted).

    btrfs rescue chunk-recover [options] <device>
        Recover the chunk tree by scanning the devices one by one.
    btrfs rescue super-recover [options] <device>
        Recover bad superblocks from good copies
    btrfs rescue zero-log <device>
        Clear the tree log. Usable if it's corrupted and prevents mount.

    btrfs restore [options] <device> <path> | -l <device>
        Try to restore files from a damaged filesystem (unmounted)

    btrfs inspect-internal inode-resolve [-v] <inode> <path>
        Get file system paths for the given inode
    btrfs inspect-internal logical-resolve [-Pv] [-s bufsize] <logical> <path>
        Get file system paths for the given logical address
    btrfs inspect-internal subvolid-resolve <subvolid> <path>
        Get file system paths for the given subvolume ID.
    btrfs inspect-internal rootid <path>
        Get tree ID of the containing subvolume of path.
    btrfs inspect-internal min-dev-size [options] <path>
        Get the minimum size the device can be shrunk to. The
    btrfs inspect-internal dump-tree [options] device
        Dump tree structures from a given device
    btrfs inspect-internal dump-super [options] device [device...]
        Dump superblock from a device in a textual form
    btrfs inspect-internal tree-stats [options] <device>
        Print various stats for trees

    btrfs property get [-t <type>] <object> [<name>]
        Gets a property from a btrfs object.
    btrfs property set [-t <type>] <object> <name> <value>
        Sets a property on a btrfs object.
    btrfs property list [-t <type>] <object>
        Lists available properties with their descriptions for the given object.

    btrfs send [-ve] [-p <parent>] [-c <clone-src>] [-f <outfile>] <subvol> [<subvol>...]
        Send the subvolume(s) to stdout.
    btrfs receive [-ve] [-f <infile>] [--max-errors <N>] <mount>
        Receive subvolumes from stdin.

    btrfs quota enable <path>
        Enable subvolume quota support for a filesystem.
    btrfs quota disable <path>
        Disable subvolume quota support for a filesystem.
    btrfs quota rescan [-sw] <path>
        Trash all qgroup numbers and scan the metadata again with the current config.

    btrfs qgroup assign [options] <src> <dst> <path>
        Assign SRC as the child qgroup of DST
    btrfs qgroup remove <src> <dst> <path>
        Remove a child qgroup SRC from DST.
    btrfs qgroup create <qgroupid> <path>
        Create a subvolume quota group.
    btrfs qgroup destroy <qgroupid> <path>
        Destroy a quota group.
    btrfs qgroup show -pcreFf [--sort=qgroupid,rfer,excl,max_rfer,max_excl] <path>
        Show subvolume quota groups.
    btrfs qgroup limit [options] <size>|none [<qgroupid>] <path>
        Set the limits a subvolume quota group.

    btrfs replace start [-Bfr] <srcdev>|<devid> <targetdev> <mount_point>
        Replace device of a btrfs filesystem.
    btrfs replace status [-1] <mount_point>
        Print status and progress information of a running device replace
    btrfs replace cancel <mount_point>
        Cancel a running device replace operation.

    btrfs help [--full]
        Display help information
    btrfs version
        Display btrfs-progs version

Use --help as an argument for information on a specific group or command.

Re: Problems with btrfs

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 2187 bytes --]



On 2018年04月29日 17:55, David C. Partridge wrote:
> Yes I did use seek=
> 
> I attach the new dump-tree - it seems very short compared to the last one you requested ???

Well, my fault, wrong spell.

# btrfs inspect dump-tree -t extent <device>

Which should give a lengthy dump.

Thanks,
Qu

> 
> Dave
> 
> -----Original Message-----
> From: Qu Wenruo [mailto:quwenruo.btrfs@gmx.com] 
> Sent: 29 April 2018 10:36
> To: David C. Partridge; linux-btrfs@vger.kernel.org
> Subject: Re: Problems with btrfs
> 
> 
> 
> On 2018年04月29日 17:20, David C. Partridge wrote:
>> Here is the result of btrfs check after applying the patch
> 
> Doesn't work as expected.
> 
> Did you apply the patched tree block with "seek="?
> 
> If so, please dump extent tree again to verify if the modification is done correct.
> 
> # btrfs inspect dump-tree -t extent <device>
> 
> Thanks,
> Qu
> 
>>
>> Dave
>> -----Original Message-----
>> From: Qu Wenruo [mailto:quwenruo.btrfs@gmx.com]
>> Sent: 29 April 2018 09:36
>> To: David C. Partridge
>> Subject: Re: Problems with btrfs
>>
>> Here is the patched binary tree block.
>>
>> You could apply them by the following command (copy1 and copy2 are the same).
>>
>> # dd if=copy1.img of=<device> bs=1 count=16K seek=25942081536 # dd 
>> if=copy1.img of=<device> bs=1 count=16K seek=26478952448
>>
>> And after that, try btrfs check to see if it reports new error.
>>
>> Thanks,
>> Qu
>>
>> On 2018年04月29日 16:24, David C. Partridge wrote:
>>> Attached as requested
>>>
>>> -----Original Message-----
>>> From: linux-btrfs-owner@vger.kernel.org 
>>> [mailto:linux-btrfs-owner@vger.kernel.org] On Behalf Of Qu Wenruo
>>> Sent: 29 April 2018 03:08
>>> To: David C. Partridge; linux-btrfs@vger.kernel.org
>>> Subject: Re: Problems with btrfs
>>>
>>>
>>>
>>> On 2018年04月29日 09:55, David C. Partridge wrote:
>>>> Not a problem
>>>>
>>>> See attached
>>>
>>> The final binary dump:
>>>
>>> # dd if=<device> of=/tmp/copy1.img bs=1 count=16K skip=25942081536 # 
>>> dd if=<device> of=/tmp/copy2.img bs=1 count=16K skip=26478952448
>>>
>>> Thanks,
>>> Qu
>>>
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Problems with btrfs

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 2495 bytes --]



On 2018年04月29日 17:59, David C. Partridge wrote:
> Here's the correct output - I mistyped inspect so I got the help output instead of the dump-tree!!! <BLUSH>
> 
> David

The archive is corrupted.
Would you mind to upload it google drive/dropbox?

Thanks,
Qu

> 
> -----Original Message-----
> From: David C. Partridge [mailto:david.partridge@perdrix.co.uk] 
> Sent: 29 April 2018 10:55
> To: 'Qu Wenruo'; 'linux-btrfs@vger.kernel.org'
> Subject: RE: Problems with btrfs
> 
> Yes I did use seek=
> 
> I attach the new dump-tree - it seems very short compared to the last one you requested ???
> 
> Dave
> 
> -----Original Message-----
> From: Qu Wenruo [mailto:quwenruo.btrfs@gmx.com] 
> Sent: 29 April 2018 10:36
> To: David C. Partridge; linux-btrfs@vger.kernel.org
> Subject: Re: Problems with btrfs
> 
> 
> 
> On 2018年04月29日 17:20, David C. Partridge wrote:
>> Here is the result of btrfs check after applying the patch
> 
> Doesn't work as expected.
> 
> Did you apply the patched tree block with "seek="?
> 
> If so, please dump extent tree again to verify if the modification is done correct.
> 
> # btrfs inspect dump-tree -t extent <device>
> 
> Thanks,
> Qu
> 
>>
>> Dave
>> -----Original Message-----
>> From: Qu Wenruo [mailto:quwenruo.btrfs@gmx.com]
>> Sent: 29 April 2018 09:36
>> To: David C. Partridge
>> Subject: Re: Problems with btrfs
>>
>> Here is the patched binary tree block.
>>
>> You could apply them by the following command (copy1 and copy2 are the same).
>>
>> # dd if=copy1.img of=<device> bs=1 count=16K seek=25942081536 # dd 
>> if=copy1.img of=<device> bs=1 count=16K seek=26478952448
>>
>> And after that, try btrfs check to see if it reports new error.
>>
>> Thanks,
>> Qu
>>
>> On 2018年04月29日 16:24, David C. Partridge wrote:
>>> Attached as requested
>>>
>>> -----Original Message-----
>>> From: linux-btrfs-owner@vger.kernel.org 
>>> [mailto:linux-btrfs-owner@vger.kernel.org] On Behalf Of Qu Wenruo
>>> Sent: 29 April 2018 03:08
>>> To: David C. Partridge; linux-btrfs@vger.kernel.org
>>> Subject: Re: Problems with btrfs
>>>
>>>
>>>
>>> On 2018年04月29日 09:55, David C. Partridge wrote:
>>>> Not a problem
>>>>
>>>> See attached
>>>
>>> The final binary dump:
>>>
>>> # dd if=<device> of=/tmp/copy1.img bs=1 count=16K skip=25942081536 # 
>>> dd if=<device> of=/tmp/copy2.img bs=1 count=16K skip=26478952448
>>>
>>> Thanks,
>>> Qu
>>>
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]