Re: [PATCH 0/7] Allow btrfsck to reset csum of all tree blocks, AKA dangerous mode.

[Qu Wenruo <quwenruo@cn.fujitsu.com>]

-------- Original Message --------
Subject: Re: [PATCH 0/7] Allow btrfsck to reset csum of all tree blocks, 
AKA dangerous mode.
From: Paul Jones <paul@pauljones.id.au>
To: Martin Steigerwald <martin@lichtvoll.de>, Qu Wenruo 
<quwenruo@cn.fujitsu.com>
Date: 2015年02月04日 18:07
>> -----Original Message-----
>> From: linux-btrfs-owner@vger.kernel.org [mailto:linux-btrfs-
>> owner@vger.kernel.org] On Behalf Of Martin Steigerwald
>> Sent: Wednesday, 4 February 2015 8:16 PM
>> To: Qu Wenruo
>> Cc: linux-btrfs@vger.kernel.org
>> Subject: Re: [PATCH 0/7] Allow btrfsck to reset csum of all tree blocks, AKA
>> dangerous mode.
>>
>> Am Mittwoch, 4. Februar 2015, 15:16:44 schrieb Qu Wenruo:
>>> Btrfs's metadata csum is a good mechanism, keeping bit error away from
>>> sensitive kernel. But such mechanism will also be too sensitive, like
>>> bit error in csum bytes or low all zero bits in nodeptr.
>>> It's a trade using "error tolerance" for stable, and is reasonable for
>>> most cases since there is DUP/RAID1/5/6/10 duplication level.
>>>
>>> But in some case, whatever for development purpose or despair user who
>>> can't tolerant all his/her inline data lost, or even crazy QA team
>>> hoping btrfs can survive heavy random bits bombing, there are some
>>> guys want to get rid of the csum protection and face the crucial raw
>>> data no matter what disaster may happen.
>>>
>>> So, introduce the new '--dangerous' (or "destruction"/"debug" if you
>>> like) option for btrfsck to reset all csum of tree blocks.
>> I often wondered about this: AFAIK if you get a csum error BTRFS makes this
>> an input/output error. For being able to access the data in place, how about a
>> "iwantmycorrupteddataback" mount option where BTRFS just logs csum
>> errors but allows one to access the files nonetheless. This could even work
>> together with remount. Maybe it would be good not to allow writing to
>> broken csum blocks, i.e. fail these with input/output error.
>>
>> This way, the csum would not be automatically fixed, *but* one is able to
>> access the broken data, *while* knowing it is broken.
>
> I seriously could have used that yesterday - I had a raw VM image with a csum error that wouldn't go away.
Is the image stored in btrfs? And you are sure the csum error belongs to 
the image?
If so, this function will not really help since the --dangerous option 
will only reset metadata csum, not
data csum.

And in that case, btrfsck --init-csum-tree  <your btrfs device> would be 
a much better choice.
> The VM worked fine (even rebooting) so I figured I would just copy the file to another filesystem and then copy it back. Rsync doesn't play nicely with errors so I used dd if=disk1 of=/elsewhere/disk1 bs=4096 conv=notrunc,noerror but after waiting for 100G to copy twice it no longer booted.
Not quite sure about conv=noerror, for case 4K OK, 4K bad, 4K OK case, 
if conv=noerror cause output to be
4K OK, 4K OK then that's the problem.
If conv=noerror cause output to be 4K OK, 4K all zero, 4K OK, then IMHO 
the problem should not happen...

Thanks,
Qu
> The backup was only 8 hours old so no big deal, but if it was a busy day that could have been nasty! (Why I didn't press the backup button before I did the above I don't know...)
>
> Paul.