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@xxxxxxx] > Sent: 29 April 2018 02:35 > To: David C. Partridge; linux-btrfs@xxxxxxxxxxxxxxx > 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@xxxxxxx] >> Sent: 28 April 2018 15:23 >> To: David C. Partridge; linux-btrfs@xxxxxxxxxxxxxxx >> 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@xxxxxxx] >>> 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@xxxxxxx] >>>> 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:
signature.asc
Description: OpenPGP digital signature
