On 2019/10/27 下午8:41, Christian Pernegger wrote:
> [Replying off-list. There shouldn't be anything private in there, but
> you never know, and it does have filenames. I'd appreciate it if you
> were to delete the data once you're sure you've gotten everything you
> can from it.]
Sure.
BTW, this use case reminds me to add an option to censor the filenames...
>
> Am So., 27. Okt. 2019 um 02:46 Uhr schrieb Qu Wenruo <quwenruo.btrfs@xxxxxxx>:
>> So "dmesg" is enough to output them.
>>
>> To find all csum error, there is the poor man's read-only scrub:
>> # find <mnt> -type f -exec cat {} > /dev/null \;
>
> I ended up diffing the files that were either in the data restored by
> btrfs restore or the ro-mount courtesy of rescue_branch, in order to
> read all files, expose files that were restored differently [1] or
> missing in one copy [just pipes & such]. Note that this is just for
> @home.
Considering you have log tree populated, it may have something to do
with log tree.
If you want to be extra safe, notreelog (yes, this time I didn't screw
up the mount option name) could make it a little safer, while make
fsync() a little slower.
Furthermore, according to your kernel log, it's not your data corrupted,
but the csum tree corrupted, thus btrfs fails to read out the csum, then
report -EIO.
It's possible that your data is just fine.
Maybe I can also enhance that part for btrfs...
Thanks,
Qu
>
> Cheers,
> C.
>
Attachment:
signature.asc
Description: OpenPGP digital signature
