Details
-
Technical task
-
Resolution: Fixed
-
Critical
-
None
-
None
-
3
-
15919
Description
Currently, when LFSCK repairs an inconsistency, it needs to take related ldlm lock(s). In the first instance, this lock prevents concurrent modifications or purge client side cache. To simplify the implementation, the LFSCK just simply acquires LCK_EX mode ibits lock(s) on related objects. For example, when insert a name entry into the namespace, it will take LCK_EX ibits lock on the parent directory, then it will prevent all others to access such directory until related repairing has been done.
Generally, if there is very little inconsistency in the system, then such lock policy is satisfactory. However, if the inconsistency cases are more common then this lock policy is inefficient. We need to consider more suitable ldlm lock mechanism, like MDT PDO lock to allow more concurrent modifications under the shard directory.
Attachments
Activity
| Resolution | New: Fixed [ 1 ] | |
| Status | Original: In Progress [ 3 ] | New: Resolved [ 5 ] |
Oleg Drokin (oleg.drokin@intel.com) merged in patch http://review.whamcloud.com/12766/
Subject: LU-5682 lfsck: optimize ldlm lock used by LFSCK
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 81be387c988787b86565f1e4087fd20809b6a7c3
| Parent |
New:
|
|
| Issue Type | Original: Improvement [ 4 ] | New: Technical task [ 7 ] |
| Fix Version/s | New: Lustre 2.8.0 [ 11113 ] |
Fan Yong (fan.yong@intel.com) uploaded a new patch: http://review.whamcloud.com/12766
Subject: LU-5682 lfsck: optimize ldlm lock used by LFSCK
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 59a432e3bb56b07c3866be1c59f12b02588f602e
| Description |
Original:
Currently, when LFSCK repairs some inconsistency, it needs to take related ldlm lock(s) firstly to prevent concurrent modifications or purge client side cache. To simply the implementation, the LFSCK just simply acquires LCK_EX mode ibits lock(s) on related object(s_. For example, when insert a name entry into the namespace, it will take LCK_EX ibits lock on the parent directory, then it will prevent all others to access such directory until related repairing has been done. Generally, if there is very little inconsistency in the system, then such lock policy can works well. But if the inconsistency cases are not too rare, then such lock policy is inefficient. We need to consider more suitable ldlm lock mechanism, like MDT PDO lock to allow more concurrent modifications under the shard directory. |
New:
Currently, when LFSCK repairs an inconsistency, it needs to take related ldlm lock(s). In the first instance, this lock prevents concurrent modifications or purge client side cache. To simplify the implementation, the LFSCK just simply acquires LCK_EX mode ibits lock(s) on related objects. For example, when insert a name entry into the namespace, it will take LCK_EX ibits lock on the parent directory, then it will prevent all others to access such directory until related repairing has been done. Generally, if there is very little inconsistency in the system, then such lock policy is satisfactory. However, if the inconsistency cases are more common then this lock policy is inefficient. We need to consider more suitable ldlm lock mechanism, like MDT PDO lock to allow more concurrent modifications under the shard directory. |
| Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
| Issue Type | Original: Bug [ 1 ] | New: Improvement [ 4 ] |
| Priority | Original: Minor [ 4 ] | New: Critical [ 2 ] |
The patch has been landed to master