On 10.11.2017 22:51 Chris Murphy wrote: >> Combined with evidence that "No space left on device" during balance can >> lead to various file corruption (we've witnessed it with MySQL), I'd day >> btrfs balance is a dangerous operation and decision to use it should be >> considered very thoroughly. > I've never heard of this. Balance is COW at the chunk level. The old > chunk is not dereferenced until it's written in the new location > correctly. Corruption during balance shouldn't be possible so if you > have a reproducer, the devs need to know about it.
I didn't say anything before, because I could not reproduce the problem. I had (I guess) a corruption caused by balance as well. It had ENOSPC in spite of enough free space (4.9.x), which made me balance it regularly to keep unallocated space around. Corruption occured probably after or shortly before power reset during a balance -- no skip_balance specified so it continued directly after mount -- data was moved relatively fast after the mount operation (copy file then delete old file). I think space_cache=v2 was active at the time. I'm of course not completely sure it was btrfs's fault and as usual not all the conditions may be relevant. Could also be instead an upper layer error (Hyper-V storage), memory issue or an application error. Regards, Martin Raiber -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
