> > I noticed that states is organized into groups even in one state > > machine.Using simplelock state machine as an example which I am most > > familiar with. In simplelock state machine, There are four groups > > (LOCK_REMOTEXLOCK is not used anymore, right?) and three stable > > states: LOCK_SYNC, LOCK_LOCK and LOCK_EXCL. In my opinion, the > > semantic of these three stable states is: > > > > LOCK_SYNC: normal state, everyone can read or readlock while no one > > want wrlock and xlock. > Right. > > > LOCK_LOCK: shared lock? I can't get it. > Hrm. I'm not sure ? Sage? Yes, it's confusing. These are better thought of as state machines controlling whether you are allowed to lock--not locks themselves. SYNC - any replica can rdlock, nobody can wrlock (shared write) or xlock (exlusive) LOCK - nobody can rdlock; only primary mds can wrlock or xlock XLOCK - somebody is holding an xlock MIX - any replica can wrlock; nobody can rdlock or xlock XLOCK is treated as unstable because as soon as the xlock is released we transition away from that state to XLOCKDONE and then to some other state, depending on who is waiting for what locks and various other factors. The xlock states are quite confusing; I would start with the others. The other thing to keep in mind is that these states *also* control what capability bits (on inodes) or leases (on dentries) we are allowed to issue to clients. Renaming a bunch of these types (e.g., s/LOCK_/ACCESSMODE_/) would probably go a long way toward making this more approachable. sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html