* Problems with btrfs
@ 2018-04-27 18:38 David C. Partridge
2018-04-28 0:20 ` Qu Wenruo
0 siblings, 1 reply; 13+ messages in thread
From: David C. Partridge @ 2018-04-27 18:38 UTC (permalink / raw)
To: linux-btrfs
[-- 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#
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problems with btrfs
2018-04-27 18:38 Problems with btrfs David C. Partridge
@ 2018-04-28 0:20 ` Qu Wenruo
2018-04-28 3:09 ` Chris Murphy
[not found] ` <003801d3def2$d90965c0$8b1c3140$@perdrix.co.uk>
0 siblings, 2 replies; 13+ messages in thread
From: Qu Wenruo @ 2018-04-28 0:20 UTC (permalink / raw)
To: David C. Partridge, linux-btrfs
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problems with btrfs
2018-04-28 0:20 ` Qu Wenruo
@ 2018-04-28 3:09 ` Chris Murphy
[not found] ` <003801d3def2$d90965c0$8b1c3140$@perdrix.co.uk>
1 sibling, 0 replies; 13+ messages in thread
From: Chris Murphy @ 2018-04-28 3:09 UTC (permalink / raw)
To: Qu Wenruo; +Cc: David C. Partridge, Btrfs BTRFS
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Problems with btrfs
[not found] ` <60674123-6fe2-2cfe-e7a8-25d62e023c53@gmx.com>
@ 2018-04-28 14:06 ` David C. Partridge
2018-04-28 14:23 ` Qu Wenruo
0 siblings, 1 reply; 13+ messages in thread
From: David C. Partridge @ 2018-04-28 14:06 UTC (permalink / raw)
To: linux-btrfs
[-- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problems with btrfs
2018-04-28 14:06 ` David C. Partridge
@ 2018-04-28 14:23 ` Qu Wenruo
2018-04-28 16:02 ` David C. Partridge
0 siblings, 1 reply; 13+ messages in thread
From: Qu Wenruo @ 2018-04-28 14:23 UTC (permalink / raw)
To: David C. Partridge, linux-btrfs
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Problems with btrfs
2018-04-28 14:23 ` Qu Wenruo
@ 2018-04-28 16:02 ` David C. Partridge
2018-04-29 1:35 ` Qu Wenruo
0 siblings, 1 reply; 13+ messages in thread
From: David C. Partridge @ 2018-04-28 16:02 UTC (permalink / raw)
To: 'Qu Wenruo', linux-btrfs
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problems with btrfs
2018-04-28 16:02 ` David C. Partridge
@ 2018-04-29 1:35 ` Qu Wenruo
[not found] ` <002f01d3df5d$25dd0270$71970750$@perdrix.co.uk>
0 siblings, 1 reply; 13+ messages in thread
From: Qu Wenruo @ 2018-04-29 1:35 UTC (permalink / raw)
To: David C. Partridge, linux-btrfs
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problems with btrfs
[not found] ` <002f01d3df5d$25dd0270$71970750$@perdrix.co.uk>
@ 2018-04-29 2:07 ` Qu Wenruo
[not found] ` <002a01d3df93$74b7b760$5e272620$@perdrix.co.uk>
0 siblings, 1 reply; 13+ messages in thread
From: Qu Wenruo @ 2018-04-29 2:07 UTC (permalink / raw)
To: David C. Partridge, linux-btrfs
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Problems with btrfs
[not found] ` <126b8a98-384e-af68-8a36-ad702f07fad2@gmx.com>
@ 2018-04-29 9:20 ` David C. Partridge
2018-04-29 9:36 ` Qu Wenruo
0 siblings, 1 reply; 13+ messages in thread
From: David C. Partridge @ 2018-04-29 9:20 UTC (permalink / raw)
To: 'Qu Wenruo', linux-btrfs
[-- 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#
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problems with btrfs
2018-04-29 9:20 ` David C. Partridge
@ 2018-04-29 9:36 ` Qu Wenruo
2018-04-29 9:55 ` David C. Partridge
[not found] ` <003501d3dfa0$ce3f1b40$6abd51c0$@perdrix.co.uk>
0 siblings, 2 replies; 13+ messages in thread
From: Qu Wenruo @ 2018-04-29 9:36 UTC (permalink / raw)
To: David C. Partridge, linux-btrfs
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: Problems with btrfs
2018-04-29 9:36 ` Qu Wenruo
@ 2018-04-29 9:55 ` David C. Partridge
2018-04-29 10:00 ` Qu Wenruo
[not found] ` <003501d3dfa0$ce3f1b40$6abd51c0$@perdrix.co.uk>
1 sibling, 1 reply; 13+ messages in thread
From: David C. Partridge @ 2018-04-29 9:55 UTC (permalink / raw)
To: 'Qu Wenruo', linux-btrfs
[-- 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problems with btrfs
2018-04-29 9:55 ` David C. Partridge
@ 2018-04-29 10:00 ` Qu Wenruo
0 siblings, 0 replies; 13+ messages in thread
From: Qu Wenruo @ 2018-04-29 10:00 UTC (permalink / raw)
To: David C. Partridge, linux-btrfs
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problems with btrfs
[not found] ` <003501d3dfa0$ce3f1b40$6abd51c0$@perdrix.co.uk>
@ 2018-04-29 10:15 ` Qu Wenruo
0 siblings, 0 replies; 13+ messages in thread
From: Qu Wenruo @ 2018-04-29 10:15 UTC (permalink / raw)
To: David C. Partridge, linux-btrfs
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2018-04-29 10:15 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-27 18:38 Problems with btrfs David C. Partridge
2018-04-28 0:20 ` Qu Wenruo
2018-04-28 3:09 ` Chris Murphy
[not found] ` <003801d3def2$d90965c0$8b1c3140$@perdrix.co.uk>
[not found] ` <a5c24cee-ad20-f317-28e8-40e88039db45@gmx.com>
[not found] ` <004d01d3def6$4000ed40$c002c7c0$@perdrix.co.uk>
[not found] ` <60674123-6fe2-2cfe-e7a8-25d62e023c53@gmx.com>
2018-04-28 14:06 ` David C. Partridge
2018-04-28 14:23 ` Qu Wenruo
2018-04-28 16:02 ` David C. Partridge
2018-04-29 1:35 ` Qu Wenruo
[not found] ` <002f01d3df5d$25dd0270$71970750$@perdrix.co.uk>
2018-04-29 2:07 ` Qu Wenruo
[not found] ` <002a01d3df93$74b7b760$5e272620$@perdrix.co.uk>
[not found] ` <126b8a98-384e-af68-8a36-ad702f07fad2@gmx.com>
2018-04-29 9:20 ` David C. Partridge
2018-04-29 9:36 ` Qu Wenruo
2018-04-29 9:55 ` David C. Partridge
2018-04-29 10:00 ` Qu Wenruo
[not found] ` <003501d3dfa0$ce3f1b40$6abd51c0$@perdrix.co.uk>
2018-04-29 10:15 ` Qu Wenruo
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.