On 2018/11/19 上午11:29, Sébastien Luttringer wrote: > On Mon, 2018-11-19 at 08:48 +0800, Qu Wenruo wrote: >> >> On 2018/11/19 上午3:37, Sébastien Luttringer wrote: >> >> You haven't post btrfs check --readonly output, thus not helpful. > > The oldest `btrfs check --readonly' output I saved is from 29th October with a > vanilla linux 4.19.0 kernel. Filename: btrfs-check-20181029.log > > A fresh `btrfs check --readonly' output was captured few minutes ago with a > 4.18.18 vanilla kernel. The file is huge (2.7 GB uncompressed, 143MB after xz > -9). Filename: btrfs-check-20181119.log.xz > > I saved a file named btrfs-check-20181119-sample.log with the first 1000 lines > for easier reading. > > You can find these files here: https://cloud.seblu.net/s/QzLk9ptSYrgofp8
Much better. Especially for btrfs-check-20181029.log. ftelephony.h has pretty bad refs. Despite that, it looks mostly OK. It looks like a bug fixed in v4.19, not sure if that's the case. However it looks like the repair makes extent tree worse, that's why --repair should only be called with developers' advice or enough experience. > >> Please post the original kernel version where you hit the first kernel >> warning. > There is a lot of first time a warning. I dont' know which one may be > relevant. > I posted the output of `journalctl -oshort-iso --no-hostname |grep -e "Linux > version" -e "BTRFS"|grep -v sdg' here : > https://cloud.seblu.net/s/QzLk9ptSYrgofp8/download?path=%2F&files=btrfs_kernever.log.xz May I ask for the oldest kernel ran on the fs? > > I excluded sdg because there is also a btrfs filesystem on it, but it's only > the system partition and there is no problem. > >> Without any useful detail, it's hard to say, but your filesystem is >> already corrupted, by the original (maybe very old) kernel. > To give you a overview of what happen: > - The backuppc process crashed randomly during backups. > - I tried scrub > => no error It's corruption in btrfs internal cross reference, while scrub only checks for csum for data/metadata, it won't detect such problem, thus btrfs check --readonly is needed. > - I tried btrfs check --readonly > => founds errors > - I tried btrfs check --repair > => segfault. > - I tried btrfs balance start --full-balance > => ok, but still errors Balance is the last thing you could try for a corrupted fs. It could make things worse, and would never ever make anything better. And it's no longer recommended to do balance routine anymore, unless you're hitting ENOPC or extreme unbalanced meta/data ratio. > - I tried btrfs balance start -mconvert=raid10,profile=raid1 > => ok, but still errors > - I tried btrfs check -p --repair --clear-space-cache /dev/sdd > => ok, but still errors > - I tried btrfs check -p --repair --clear-space-cache v2 /dev/sdd > => ok, but still errors > - I tried btrfs check -p --mode lowmem /dev/sdd > => segfault (after long time) > - btrfs check --init-csum-tree /dev/sdd > => abort To make it clear again, any --init-* should only be used when you're completely sure what is going to happen (at code level). From btrfs-check-20181119, all the extra damage are possibly caused by either --repair or this --init-csum-tree. > >> Thus newer kernel can't process on the corrupted fs. > Is there tools which can fix these issue? From 20181029, it may be possible with extra help from btrfs-progs developers. But at current point, it's near impossible to recover it to a fully functional state. > > Looks like I can still access to the data in read-only, despite the wrong size > of filesystem displayed in 'df -h' or 'btrfs fi us /home'. The original corruption is only for some strange dir refs, thus no problem for other files/directories, but could cause problem when updating dir refs, just as the original kernel warning shows. The new corruption is some extent tree mismatch, thus only damage write operations. Thanks, Qu > > Regards, > > Sébastien "Seblu" Luttringer >
signature.asc
Description: OpenPGP digital signature
