[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gfs-devel
Subject:    Proposed Dlock 0.9.6 Changes V2
From:       Ken Preslan <kpreslan () zarniwoop ! com>
Date:       2000-04-19 9:04:13
[Download RAW message or body]

I think new version contains everything people suggested.
Any other changes or additions?


Proposed features of Dlock 0.9.6 (version 2)


1)  Mandatory Sparse Lock Space

Logical Lock Numbers (that are passed in the CDB) are dynamicly mapped to
Physical Locks in the Dlock device.  When a new Logical Lock is
locked, a new Physical Lock is created (or reclaimed from free pool, LRU
list, or whatever) and assigned to that LLN.

Logical Lock Numbers no longer run from 0 to n-1.

A Physical Lock can be recycled to a new Logical Lock Number only if there are
no holders (Live, Expired, or Conversion).

An important point is that this doesn't mean the Dlock device must do 
dynamic allocation.  There can be a constant number of Physical Locks
allocated at device initialization.  The Physical Locks can then be arranged
in hash table of linked-lists of Physical Locks.  The hash maps the LLN
to a hash bucket and that bucket is traversed to find (or not find) the
correct Physical Lock.
     We should point this out as a possible implementation, but it's 
definitely not the only one.  A picture of this would probably be worth while.

Niffty things this does for GFS:

With a non-sparse lock space, many inodes map to each lock.
  - This causes unecessary contention.
  - It also makes lock ordering (deadlock avoidance) much harder.  Ordering
	can't be done on inodes it must be done on lock numbers.
  - Locks are also potentially wasted.  In GFS, each resource group gets
	a certain number of locks.  All inodes in that resource group map
	to those locks.  If the resource group is filled with data, some of
	the locks in the RG may not ever map to any inode.

With a sparse lock space, there is a one-to-one mapping between
locks and inodes.  The above problems go away.  In the simplest case:
  LLN = Inode# + Offset

It is also possible to go even further and set aside some of the bits of
the LLN to allow multiple locks per inode.  It's possible each inode has a
metadata lock, a data lock, a file lock, a "Nopen" lock, and who knows
what else.
  LLN = Inode# * 4 + LockType + Offset    (in the case of four locks per inode)

2)  A bigger Lock Number field and a smaller Client ID field

Logical Lock Numbers are 64-bit.
Client IDs are 16-bit.

(8-byte LN, 2-byte CID, 2-byte AllocLen, 1-byte reserved)

Zero is an invalid value for both Lock Numbers and CIDs.

3)  Running out of locks

The one added wrinkle that sparse lock spaces add is the possiblity of 
running out of free Physical Locks when a new LLN is requested.

If all the Physical Locks have holders and a request comes in for a new LLN,
the Dlock action returns with a Result bit of 0.  Also, a "Full" bit is set
in the RDF to let the initiator know that this has happened.

5)  Return Live Holders action

An action that returns an RDF containing a list of the Live Clients holding
locks on a device.

After getting a "Full" bit back from a lock request, the initiator can send
a Return Live action to the device.  It can then use an out-of-bounds
callback to ask the clients to drop some of their locks.

6)  Mode Page changes

The "Number of Locks" field should contain an approximate value for the
number of Physical Locks the device supports.

7)  No Version Numbers

Maintaining version numbers in a sparse lock space is difficult.  If a LLN
moves from being mapped to one PL to another, the version number will change
arbitarily.

It's difficult to tell multiple clients whether or not the version number
they get back in the RDF is at all related a previously stored copy.

But when GFS clients aggressively cache locks (and does promotion/demotions
instead of locks and unlocks), version numbers offer less of an advantage
than they did before.  The only time a client releases a lock is when another
client wants to modify the data protected by that lock.

The Unlock Increment and Demote Increment actions go away.  There is no
version number in the RDF.

8)  RDF contains the lock number

The first eight bytes of the RDF contain the lock number this response
corresponds to.


-- 
Ken Preslan <kpreslan@zarniwoop.com>


-
To unsubscribe from this list: send the line "unsubscribe gfs-devel" in
the body of a message to majordomo@borg.umn.edu
Read the GFS Howto:  http://www.globalfilesystem.org/howtos/gfs_howto/

[prev in list] [next in list] [prev in thread] [next in thread]