On 2019/12/22 下午5:00, Swâmi Petaramesh wrote: > Hi again, > > Le 22/12/2019 à 09:12, Qu Wenruo a écrit : >> So if you have enough uncommitted metadata, that check will be triggered >> and suddenly returns 0 available space, even 1 sec early you still get >> tons of available space. > > With « uncommitted metadata » do you mean that this situation is only > temporary and should end once all transactions are commited to disk ? Yes. The temporary part also matches with one kind reporter's description. So for that v5.4 temporary 0 available, it should be the case. > > Because in the one disk on which I observe this (and which passes a full > btrfs check with bells and whistles) it still shows 0% free after 2 days > and several unmounts / remounts... > > Furthermore I've conected it to machines using 5.3 and even 4.15 > kernels, and they *ALL* state that the free disk space is zero - even > though I can understand if « That check is from 2015 ». Then for older kernels, I'm afraid you're seeing a different problem. If you feel like to try to start hacking the kernel, I could provide some snippet to add debug output and pin down the problem. But there is one valid behavior which may cause such 0 available space situation. Are you using RAID1 or RAID10 with hugely unbalanced disk size? If so, there could be a case that btrfs can't find two devices with enough un-allocated space to fulfill a chunk allocation. E.g. 1T + 1T + 10T disks RAID1. You can only utilize 2T space (1T from each smaller devices, and 2T from that larger device). The remaining 8T from that larger device can't be utilized for RAID1. In that case, you will still have unallocated space, but any profile requiring two disks is unable to use it. > > That still seems to boild down to : Once I got this error it seems I > cannot step out of it using any reasonably recent kernel. > > So I may have either to patch my kernel or wait for the patch to reach > #Arch kernels... and hope it actually fixes it. > > (I have to admit that I haven't yet fully understood the technical > aspects of this overcommit story...) > > I'm also worried that on my machines that does NOT show this problem on > their own main filesystems, this could happen anytime soon ? We need extra info to further determine the cause of the persistent 0 available space problem. `btrfs fi usage` output would help a lot. But still, that 2015 check can still cause 0 available space, if your metadata available space is pretty low. Thanks, Qu > > Thanks anyway very much for your help. > > Kind regards. > > ॐ >
