On 4/2/19 5:04 PM, Nik. wrote: > > > 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... No, we're saying that the memory (hardware) in your computer is not reliable, and it's corrupting memory pages before thet gets checksummed and written out to disk. When reading this metadata back later, the filesystem explodes because the contents are invalid. >> So, 146075 is actually 15003, but with a bit flipped from 0 to 1. >> >>> This should ring a little alert about the problem. Hans
