On 22/11/2019 13:10, Qu Wenruo wrote: > > On 2019/11/22 下午8:37, devel@xxxxxxxxxxxxxx wrote: >> So been discussing this on IRC but looks like more sage advice is needed. > You're not the only one hitting the bug. (Not sure if that makes you > feel a little better) Hehe.. well always help to know you are not slowly going crazy by oneself. >> >> The csum error is from data reloc tree, which is a tree to record the >> new (relocated) data. >> So the good news is, your old data is not corrupted, and since we hit >> EIO before switching tree blocks, the corrupted data is just deleted. >> >> And I have also seen the bug just using single device, with DUP meta and >> SINGLE data, so I believe there is something wrong with the data reloc tree. >> The problem here is, I can't find a way to reproduce it, so it will take >> us a longer time to debug. >> >> >> Despite that, have you seen any other problem? Especially ENOSPC (needs >> enospc_debug mount option). >> The only time I hit it, I was debugging ENOSPC bug of relocation. >> As far as I can tell the rest of the filesystem works normally. Like I show scrubs clean etc.. I have not actively added much new data since the whole point is to balance the fs so a scrub does not take 18 hours. So really I am not sure what to do. It only seems to appear during a balance, which as far as I know is a much needed regular maintenance tool to keep a fs healthy, which is why it is part of the btrfsmaintenance tools Are there some other tests to try and isolate what the problem appears to be? Thanks. -- == D LoCascio Director RooSoft Ltd
