Re: interest in post-mortem examination of a BTRFS system and improving the btrfs-code?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





2019-04-03 03:04, Qu Wenruo:


[snip]
...

In your case, you just need latest btrfs-progs and re-run "btrfs check
--readonly" on it.

Will try this, but have no time before tomorrow evening.


If it just shows the same result, meaning I can't get the info about
which tree block is corrupted, then you could try to mount it with -o ro
using *LATEST* kernel.

I tried this before with the 4.15.0-46 kernel, it was impossible. Will
try again with newer one as soon as possible (in best case tomorrow
evening); I will post the results.

Sorry for the delay, compiling the btrfs-progs took much more time than expected (had to install new packages again and again). Finally had to give up the conversion ("make" could not find reiserfs/misc.h, although both libreiserfscore and reiser4fs are installed).
Output of the commands:
# uname -r
5.0.6-050006-generic
#btrfs --version
btrfs-progs v4.20.2
# btrfs check --readonly /dev/md0
Opening filesystem to check...
incorrect offsets 15003 146075
ERROR: cannot open file system

It seems that I will wait until 5.2 is out...
(the answer to Jeff Mahoney is coming with separate e-mail!)

Latest kernel will report anything wrong pretty vocally, in that case,
dmesg would include the bytenr of corrupted tree block.

Then I could craft needed commands to further debug the fs.

Ok, I will try to post more info tomorrow about this time.

Nik.
--

Thanks,
Qu


Thank you for trying to improve btrfs!

Nik.

Thanks,
Qu

You are not from the 007 - lab, are you? ;-)


Kind regards,

Nik.






[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux