cluster/afr: cleanup lk_owner and PID mess

Historically PID (frame->root->pid) was used by the locks translator
to identify a locker (and make decisions about which locks contend
or cooperate/merge). Since the introduction of lock_owner parameter
the usage of PID (for locks) was deprecated and is now unused. This
patch nukes the usage of PID in AFR

The usage of lk_owner has also ended up being a mess, because of the
differentiation required between ->lk() and ->inodelk(), (->lk() needs
to be identified by the process (roughly) and ->inodelk() needs to be
identified by the transaction) and also because of optimizations like
eager locking (locks are no more identified by the transaction as they
now get inherited by the next transaction).

The scheme (and technique) now is:

- All FOPs (the third phase of the transaction) happen with the lk_owner
  which is set by the topmost layer (FUSE, NFS etc.)

- All entrylks are issued with lk_owner set to the frame->root address.

- Inodelks which will not be subject to eager locking are issued with
  lk_owner set to frame->root.

- Inodelks which are subject to eager locking are issued with lk_owner
  set to the address of fd_t (which are the only type of frames which
  get subject to the eager locking optimization)

- At the start of the transaction, the transaction frame's lk_owner is
  set to the either frame->root or fd_t (and never unmodified) depending
  on the type of transaction.

- Just before the third phase (FOP phase) the set lk_owner is "saved"
  away and overwritten by the lk_owner submitted by the top layer (FUSE
  or NFS)

- Right after the third phase, the saved lk_owner is "restored" to resume
  the transaction into the POST-OP and eventually UNLOCK using the same
  lk_owner which was used during the LOCK phase.

Change-Id: I6ab8e4d6b65ae4185fa85ad3fded8e9188b2f929
BUG: 836033
Signed-off-by: Anand Avati <avati@redhat.com>
Reviewed-on: http://review.gluster.com/3620
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Pranith Kumar Karampuri <pranithk@gluster.com>

0 files changed, 0 insertions, 0 deletions