2018-01-10 21:33 GMT+03:00 Tom Worster <f...@thefsb.org>: > On 10 Jan 2018, at 12:01, Austin S. Hemmelgarn wrote: > >> On 2018-01-10 11:30, Tom Worster wrote: >> >> Also, for future reference, the term we typically use is ENOSPC, as that's >> the symbolic name for the error code you get when this happens (or when your >> filesystem is just normally full), but I actually kind of like your name for >> it too, it conveys the exact condition being discussed in a way that should >> be a bit easier for non-technical types to understand. > > > Iiuc, ENOSPC is _exhaustion_ of unallocated space, which is a specific case > of depletion. > > I sought a term to refer to the phenomenon of unallocated space shrinking > beyond what filesystem use would demand and how it ratchets down. Hence a > sysop needs to manage DoUS. ENOSPC is likely a failure of such management. > > >>> - Some experienced users say that, to resolve a problem with DoUS, they >>> would rather recreate the filesystem than run balance. >> >> This is kind of independent of BTRFS. > > > Yes. I mentioned it only because it was, to me, a striking statement of lack > of confidence in balance. > > >>> But if Duncan is right (which, for me, is practically the same as >>> consensus on the proposition) that problems with corruption while running >>> balance are associated with heavy coincident IO activity, then I can see a >>> reasonable way forwards. I can even see how general recommendations for >>> BTRFS maintenance might develop. >> >> As I commented above, I would tend to believe Duncan is right in this case >> (both because it makes sense, and because he seems to generally be right >> about this type of thing). That said, I really do think that normal user >> I/O is probably not the issue, but low-level filesystem operations are. >> That said, there is no reason that BTRFS shouldn't either: >> 1. Handle this just fine without causing corruption. >> or: >> 2. Extend the mutex used to prevent concurrent balances to cover other >> operations that might cause issues (that is, make it so you can't scrub a >> filesystem while it's being balanced, or defragment it, or whatever else). > > > Yes, but backtracking a bit, I think there's another really important point > here. Assuming Duncan's right, it's not so hard to develop guidelines for > general BTRFS management that include DoUS among other topics. Duncan's > other email today contains or implies quite a lot of those guidelines. > > Or, to put it another way, it's enough for me. I think I know what to do > now. And that much could be written down for the benefit of others. > > Tom > > > -- > 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
My two cents, I've about ~50 different systems (VCS Systems, MySQL DB, Web Servers, Elastic Search nodes & etc.). All running btrfs only and run fine, even with auto snapshot rotating on some of them, (btrfs make my life easier and i like it). Most of them are small VMs From 3GiB..512GiB (I use compression everywhere). And no one of them need balance, only that i care, i try have always some unallocated space on it. Most of them are stuck with some used/allocated/unallocated ratio. I.e. as i see from conversation point of view. We run balance for reallocate data -> make more unallocated space, but if someone have plenty of it, that useless, no? ex. I've 60% allocated by data/meta data chunks on my notebook, And only 40% are really used by data, even then i have 90% allocated, and 85% used, i don't face into ENOSPC problems. (256GiB ssd). And if i run balance, i run it only to fight with btrfs discard processing bug, which leads to trim only unallocated space (probably fixed already). So if we talk about "regular" running of balance, may be that make a sense To check free space, i.e. if system have some percentage of space allocated, like 80%, and have plenty of allocated/unused space, only then balance will be needed, no? (I'm not say that btrfs have no problems, i see some rare hateful bugs, on some systems, but most of them are internal btrfs problems or problems with coop of btrfs with applications). Thanks. -- Have a nice day, Timofey. -- 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
