2019-04-02 16:19, Hans van Kranenburg:
On 4/2/19 4:12 PM, Qu Wenruo wrote:
On 2019/4/2 下午9:59, Nik. wrote:
2019-04-02 15:24, Qu Wenruo:
On 2019/4/2 下午9:06, Nik. wrote:
If the larger fs really doesn't get any write (btrfs check --repair
failed to open the fs, thus have the output "cannot open file system"),
I'm interesting in that one.
This is excerpt from the terminal log:
"# btrfs check --readonly /dev/md0
incorrect offsets 15003 146075
ERROR: cannot open file system
#"
That's great.
And to my surprise, this is completely different problem.
And I believe, it will be detected by latest write time tree checker
patches in next kernel release.
This problem is normally caused by memory bit flip.
To illustrate for whoever needs it to follow this reasoning:
bin(146075) -> 0b100011101010011011
bin(15003) -> 0b11101010011011
Wait a minute! I hope you are not saying that the file system grew too
much for addressing it on a 32bit architecture (inappropriate variable
type somewhere in the code)? Because the problem came shortly after
adding another drive to the file system...
So, 146075 is actually 15003, but with a bit flipped from 0 to 1.
This should ring a little alert about the problem.
Hans
