Docadmin at 21:09, 22 January 2010

2010-01-22T21:09:14Z

← Older revision		Revision as of 14:09, 22 January 2010
Line 1:		Line 1:
	'''''Note:''''' The content on this page reflects the state of design of a Lustre feature at a particular point in time and may contain outdated information.		'''''Note:''''' ''The content on this page reflects the state of design of a Lustre feature at a particular point in time and may contain outdated information.''

	== Definitions ==		== Definitions ==

Docadmin: Protected "Architecture - External File Locking" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

2010-01-21T19:33:24Z

Protected "Architecture - External File Locking" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

← Older revision	Revision as of 12:33, 21 January 2010
(No difference)

Docadmin: /* Definitions */

2010-01-18T23:57:12Z

Definitions

← Older revision		Revision as of 16:57, 18 January 2010
Line 1:		Line 1:
			'''''Note:''''' The content on this page reflects the state of design of a Lustre feature at a particular point in time and may contain outdated information.

	== Definitions ==		== Definitions ==

Docadmin: /* References */

2010-01-14T22:11:39Z

References

← Older revision		Revision as of 15:11, 14 January 2010
Line 129:		Line 129:
	* flock recovery as [https://bugzilla.lustre.org/show_bug.cgi?id=11880 bug 11880]		* flock recovery as [https://bugzilla.lustre.org/show_bug.cgi?id=11880 bug 11880]
	* flock and MPI-IO issues as [https://bugzilla.lustre.org/show_bug.cgi?id=11660 bug 11660]		* flock and MPI-IO issues as [https://bugzilla.lustre.org/show_bug.cgi?id=11660 bug 11660]

	~~[[Category:Architecture\|External File Locking]]~~
	~~[[Category:QAS\|External File Locking]]~~

Docadmin: moved External File Locking to Architecture - External File Locking

2010-01-14T21:20:45Z

moved External File Locking to Architecture - External File Locking

← Older revision	Revision as of 14:20, 14 January 2010
(No difference)

Docadmin: 1 revision

2010-01-14T21:01:06Z

1 revision

← Older revision	Revision as of 14:01, 14 January 2010
(No difference)

Nikita: update categories to match (changed) page title.

2007-08-14T10:21:26Z

update categories to match (changed) page title.

New page

== Definitions ==

; '''POSIX file lock''', '''lockf lock''', '''fcntl lock''' : file range lock obtained through one of file range locking interfaces prescribed by POSIX and based on SysV [http://www.opengroup.org/onlinepubs/000095399/functions/lockf.html lockf()] and [http://www.opengroup.org/onlinepubs/000095399/functions/fcntl.html fcntl()] interfaces.
; '''flock lock''' : whole-file lock obtained through BSD [http://man.cx/flock(2) flock] interface.
; '''group lock''' : whole-file lock obtained through Lustre-specific '''LL_IOC_GROUP_LOCK''' ioctl().
; '''file lock''' : either of above locks.

== Use Cases ==

{| border=1 cellspacing=0
|-
!id !! quality attribute !! summary
|-
|posix-and-flock || usability || Both POSIX and flock locking is supported.
|-
|EDEADLK || usability, availability || Faithful dead-lock detection.
|-
|lock-recovery || availability || The cluster on which migrations are active suffers a failure. File locks are recovered properly.
|-
|scalability || usability, performance || No service degradation in case of very wide striping and file lock contention.
|-
|unit-tests || testability || Unit tests for flock usage and dead-lock detection.
|-
|}

=== posix-and-flock ===

{|border=1 cellspacing="0"
|-align="left"
|colspan=2|'''Scenario:''' || Both POSIX and flock locks are being taken over overlapping regions of the same file.
|-align="left"
|colspan=2|'''Business Goals:''' || Avoid interaction between different locking interfaces.
|-align="left"
|colspan=2|'''Relevant QA's:'''|| Usability
|-align="left"
|rowspan="6" writing-mode="vertical"|'''details'''
| '''Stimulus:'''|| Two threads on the same client or threads from different clients obtain flock and lockf locks on the overlapping regions of the same file.
|-align="left"
|'''Stimulus source:'''|| User applications.
|-align="left"
|'''Environment:'''|| File being locked.
|-align="left"
|'''Artifact:'''|| Overlapping locks of different flavours.
|-align="left"
|'''Response:'''|| No interaction between locks.
|-align="left"
|'''Response measure:'''|| Clients do not block or dead-lock on such locks.
|-align="left"
|colspan=2|'''Questions:'''|| This is traditional Linux behaviour. Do we want to reproduce it?
|-align="left"
|colspan=2|'''Issues:'''|| None.
|-
|}

=== -EDEADLK ===

{|border=1 cellspacing="0"
|-align="left"
|colspan=2|'''Scenario:''' || Client places blocking file lock request on server that would result in dead-lock if processed.
|-align="left"
|colspan=2|'''Business Goals:''' || Avoid dead-locks.
|-align="left"
|colspan=2|'''Relevant QA's:'''|| Usability & Availability
|-align="left"
|rowspan="6" writing-mode="vertical"|'''details'''
| '''Stimulus:'''|| Client tries to acquire lock, resulting in possible dead-lock.
|-align="left"
|'''Stimulus source:'''|| User applications.
|-align="left"
|'''Environment:'''|| Locks.
|-align="left"
|'''Artifact:'''|| Waiting cycle among locks.
|-align="left"
|'''Response:'''|| Dead-lock is detected.
|-align="left"
|'''Response measure:'''|| Lock request is denied with -EDEADLK error.
|-align="left"
|colspan=2|'''Questions:'''|| How precise dead-lock detection has to be, i.e., is server permitted to return -EDEADLK sporadically when no actual dead-lock is possible? How sound dead-lock detection has to be, i.e., is server permitted to occasionally miss dead-lock?
|-align="left"
|colspan=2|'''Issues:'''|| Precise and sound dead-lock detection can be quite intricate. In addition, it basically mandates keeping track of all file locks in a single place within cluster, which conflicts with scalability requirement.
|-
|}

=== recovery ===

TBD.

=== scalability ===

{|border=1 cellspacing="0"
|-align="left"
|colspan=2|'''Scenario:''' || Large number of locks is created. Locks are contended by clients.
|-align="left"
|colspan=2|'''Business Goals:''' || Ascertain graceful service degradation.
|-align="left"
|colspan=2|'''Relevant QA's:'''|| Usability & Performance
|-align="left"
|rowspan="6" writing-mode="vertical"|'''details'''
| '''Stimulus:'''|| Clients obtains large number of locks, and place large number of lock requests waiting to be granted.
|-align="left"
|'''Stimulus source:'''|| User applications.
|-align="left"
|'''Environment:'''|| Servers handling locks.
|-align="left"
|'''Artifact:'''|| Large number of locks and lock requests.
|-align="left"
|'''Response:'''|| Algorithms handle this situation gracefully.
|-align="left"
|'''Response measure:'''|| No server overload.
|-align="left"
|colspan=2|'''Questions:'''||
|-align="left"
|colspan=2|'''Issues:'''|| Conflicts with dead-lock detection somewhat.
|-
|}

== Implementation constraints ==

Use DLM to implement flock.

== Questions and Issues ==

* any special handling for liblustre?
* do we want file locks to be kept on LRU list by clients?

== References ==

* Implementation as [https://bugzilla.lustre.org/show_bug.cgi?id=5506 bug 5506]
* flock recovery as [https://bugzilla.lustre.org/show_bug.cgi?id=11880 bug 11880]
* flock and MPI-IO issues as [https://bugzilla.lustre.org/show_bug.cgi?id=11660 bug 11660]

[[Category:Architecture|External File Locking]]
[[Category:QAS|External File Locking]]