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 > 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 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 - I tried btrfs check --readonly => founds errors - I tried btrfs check --repair => segfault. - I tried btrfs balance start --full-balance => ok, but still errors - 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 > Thus newer kernel can't process on the corrupted fs. Is there tools which can fix these issue? 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'. Regards, Sébastien "Seblu" Luttringer
signature.asc
Description: This is a digitally signed message part
