On 9 Jan 2018, at 22:49, Duncan wrote:
AFAIK, such corruption reports re balance aren't really balance, per
se,
at all.
Instead, what I've seen in nearly all cases is a number of filesystem
maintenance commands involving heavy I/O colliding, that is, being run
at
the same time
I hope there is consensus on this because it might be the key to
resolving the contradictions that appear to me in the following
propositions that all seem plausible/reasonable:
- Depletion of unallocated space (DoUS, apologies for coining the term
if there already is one) is a property of BTRFS even if the volume's
capacity is more than enough for the files on it.
- To a user that isn't a BTRFS expert, DoUS can be unexpected, its
advance can be surprisingly fast and it can become severe.
- BTRFS does not recycle allocated but unused space to the unallocated
pool.
- Resolving severe DoUS involves either running `btrfs balance` or
recreating the filesystem from, e.g. backups.
- People have reported that `btrfs balance` sometimes causes filesystem
corruption.
- Some experienced users say that, to resolve a problem with DoUS, they
would rather recreate the filesystem than run balance.
- Some experienced users say you should stop all other use of the
filesystem while running balance.
- Some experts recommend running balance regularly, even once a day, to
prevent DoUS.
Without some satisfactory way to resolve the contradictions, I'm not
sure how to proceed. For example, I'm not willing to offload the
workload from each filesystem once a day for prophylactic balance. And
I'm not going to let balance run unattended if those more experienced
than me say it's known to corrupt filesystems. The best I can do is
monitor DoUS and respond ad hoc. Or I can use a different fs type.
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.
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
