Thanks Jon, I was in the process of updating the doc, but got carried away with more pressing issues. I'll attach an updated version.
Your overview seems about right.
This primarily protects operations that clash with table level enable/disable/alter, but not region level operations, right?.
If you mean assign, etc. Not it does not.
This doesn't guard meta from individual changes, right? It only protects meta from bulk adds (create/delete table). Thus this shouldn't affect region moves or region closes/opens.
There is no guard against changes to META. Region moves, open/close does not acquire a lock.
If an overlapping merge and split were issued, some other mechanism is in place to keep this sane right? This doesn't protect multiple merge requests with overlapping regions right?
Merges will likely want the read lock? (allowing multiple concurrent merges, and assuming some overlap sanity protection from a different mechanism).
Merges can be designed to acquire read lock or a write lock. If read lock, then it means there is no guarantee against trying to do a merge and a concurrent split. But this allows merges for different ranges happening at the same time. If we do write lock, it will guard against concurrent merge / split problem, but we cannot do multiple merges at the same time.
The recent patch for
HBASE-7403 moves the regions to be merged to the same region server. We might be able to do in-memory locking for merge and split in the RS, so that we might be able to use read locking for merges.
With snapshots, this mechanism doesn't prevent regions from moving so it only protects snapshots from concurrently happening with enable/disable/alter table ops. Snapshot will still fail if it gets caught while the balancer is running.
Yes, there is no protection against that right now. I have to look up why region move causes snapshot to fail.
These locks don't really help hbck – except for the cases where enable/disable/alter operations are going on as hbck repairs things. (It wouldn't "protect" hbck from the balancer").
hbck as it is relies too much on knowing about the filesystem layout, and META. It is hard to sync between balancer and hbck.
Does having a table lock (and then having individual region locks that require a table read lock being held) make sense? Maybe this makes sense for merges and splits?
If we have per-region locks, we might reevaluate table locks. But I would imagine so, since it will prevent concurrent master operations as well. We can achieve the same thing with acquiring all the region locks, but table locks would be faster.
having individual region locks that require a table read lock being held
I think we have to evaluate whether this is feasible. I guess it should be, but we should be able to scale to millions of regions. If we had per-region locks, assignment would become much easier (current RIT is similar, but we need this even for assigned regions)