On 06/04/2018 11:30 PM, Qu Wenruo wrote:
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.
Ok great to hear! I'll give it a test whenver you have it.
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
