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
