On 2018年05月29日 22:58, Steve Leung wrote:
> Qu Wenruo <quwenruo.btrfs@gmx.com> writes:
> 
>> On 2018年05月28日 11:47, Steve Leung wrote:
>>> On 05/26/2018 06:57 PM, Qu Wenruo wrote:
>>>>
>>>>
[snip]
>> Still nope.
>> What about encrypt it and upload it to some public storage provider like
>> google drive/dropbox?
> 
> Ok, uploaded to Google Drive.  You'll need to request access to it.
> 
>   https://drive.google.com/file/d/16NM1NVoMVgkJ_JiePi8VfAzit5_Onz2H/view?usp=sharing
> 
> sha256sum for the file should be:
> 
>   ea0abc21fcbc3a71c68b7307d57b26763ac711bd3437a60e32db3144facfeb3f
Sorry for the slow reply.

After all the testing, the result is a little surprising.

It's indeed *CORRUPTED*! And tree-checker code exposed it.

It's just btrfs-progs and kernel print-tree code doesn't use correct
ram_bytes to output, thus pretty tricky to expose.

The problem is the ram_bytes of that inlined extent, it's indeed larger
than it should, just by one byte.

I'm not completely sure how it's happened, but according to the
timestamp it's 4 years ago and I think some kernel off-by-one error
happens and fixed.

And current kernel can handle it pretty well without reading out the
last byte.
However it's still a corruption.

Although it's not a big problem, and can be fixed easily.
I'll submit a btrfs-progs patch to allow btrfs-check to fix in this week.

Thanks,
Qu

> Thanks!
> 
> Steve
>