src/ceph/src/doc/mds_locks.txt

   1
   2 new names
   3  dentry_read  (not path_pins)
   4  dentry_xlock
   5
   6  inode_read
   7  inode_xlock  (not inode_write)
   8
   9 locks are always tied to active_requests.
  10
  11 read locks can be placed on any node.
  12 xlocks must be applied at the authority.
  13
  14 for multi-lock operations (link, unlink, rename), we must acquire xlocks on a remote node.  lock requests are associated with a reqid.  the authoritative node keeps track of which remote xlocks it holds.  when forwarded/restarted, it can drop remote locks.
  15
  16 when restarting, drop all locks.
  17 on remote, drop locks and state, and notify main req node.
  18 recover dist request state on rejoin:
  19  - surviving op initiator will assert read or xlock
  20  - recovering op initiator will restart requests.  (from initiator's perspective, ops have either happened or they haven't, depending on whether the event is journaled.)
  21  - recovering or surviving op cohort will determine lock state during rejoin, or get a commit or rollback...
  22  -
  23
  24
  25 --- path_pin = read lock on /some/random/path
  26   - blocks a dentry xlock
  27
  28 --- dnxlock = exclusive lock on /some/random/path
  29   - locking: prevents subsequent path pins.
  30   - locked: prevents dn read
  31   - on auth
  32
  33 -> grab _all_ path pins at onces; hold none while waiting.
  34 -> grab xlocks in order.
  35
  36 --- auth_pin = pin to authority, on *dir, *in
  37   - prevents freezing -> frozen.
  38     - freezing blocks new auth pins, thus blocking other local auth_pins.  (hangs up local export.)
  39     - does not block remote auth_pins, because remote side is not auth (or frozen!) until after local subtree is frozen.
  40
  41 -> blocking on auth_pins is dangerous.  _never_ block if we are holding other auth_pins on the same node (subtree?).
  42 -> grab _all_ auth pins at once; hold none while waiting.
  43
  44 --- hard/file_wrlock = exlusive lock on inode content
  45   - prevents inode read
  46   - on auth
  47
  48 -> grab locks in order.
  49
  50
  51 ORDERING
  52 - namespace(dentries) < inodes
  53 - order dentries on (dirino, dname)
  54 - order inodes on (ino);
  55 - need to order both read and write locks, esp with dentries.  so, if we need to lock /usr/bin/foo with read on usr and bin and xwrite on foo, we need to acquire all of those locks using the same ordering.
  56   - on same host, we can be 'nice' and check lockability of all items, then lock all, and drop everything while waiting.  (actually, is there any use to this?)
  57   - on mutiple hosts, we need to use full ordering (at least as things separate across host boundaries).  and if needed lock set changes (such that the order of already acquired locks changes), we need to drop those locks and start over.
  58
  59 - how do auth pins fit into all this?
  60   - auth pin on xlocks only.  no need on read locks.
  61   - pre-grab all auth pins on a node the first time it is visiting during lock acquisition.
  62     - what if things move?  if we find we are missing a needed auth pin when we revisit a host at any point, and the item is not still authpinnable, we back off and restart.  (we cannot block.)
  63   -
  64   - if we find we are not authpinnable, drop all locks and wait.
  65
  66