Here are the dumps you requested. -----Original Message----- From: Qu Wenruo [mailto:quwenruo.bt...@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.bt...@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.bt...@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 >>> >> >
copy1.img
Description: Binary data
copy2.img
Description: Binary data
