On 2018年05月29日 22:58, Steve Leung wrote: > Qu Wenruo <quwenruo.btrfs@xxxxxxx> 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 >
Attachment:
signature.asc
Description: OpenPGP digital signature
