[LU-16669] Add lock_no_expand tunable on the Lustre client

• Status: Open
• Project: Lustre
• Type: Improvement
• Priority: Minor
• Reporter: Qian Yingjin
• Assignee: Qian Yingjin
• Resolution: Unresolved

Description

Lustre advise IOCTL interface can set the CEF_LOCK_NO_EXPAND flag, which tells the OSC (the per OST layer of the client) to set LDLM_FL_NO_EXPANSION on any lock requests. LDLM_FL_NO_EXPANSION is a new LDLM lock flag which tells the server not to expand the lock extent.

To set this parameter much easier for benchmark or debug purpose, It would better to add a tunable "llite.*.lock_no_expand" to control whether to expand the lock extent for I/O.

Issue Links

• is related to: LU-16939 ldlm: not expand the lock extent when...

Comments

[Gerrit Updater]

"Qian Yingjin <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/50432
Subject: LU-16669 llite: add lock_no_expand tunable on a client
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: b5cb732703272e4919e9e3c7af2bb8b88498e287

[Andreas Dilger]

Yingjin, could you please provide some background on what this is needed for? I don't see it linked to any other tickets, and there isn't enough explanation in the description to know what this would be used for.

I'm wondering if we should add a new LF_INODE flag so that "lfs ladvise locknoexpand <file>" could be set persistently on an inode rather than just a file descriptor? Would that be more useful for applications or test scripts instead of adding a CFS_FAIL_CHECK() that affects all files on the node?

[Qian Yingjin]

Hi Andreas,

There are two motivations for this work:

• It is mainly used for benchmark purpose;
• Strided writes from many clients with page aligned. It does expand the I/O locking extent to reduce the lock ping-pong callbacks. (compared with strided writes using direct I/O).

Of course we can add a new LF_INODE flag to be set persistently on an inode for "lfs ladies locknoexpand $file".

But I am just worried about its narrow usage scope...

[Andreas Dilger]

I think in the second case, it makes sense for the client or OSS to detect the lock contention and avoid lock expansion. This already happens on the OSS today with 32+ clients writing to a single file, but it does not take into account disjoint writes with fewer clients.

[Qian Yingjin]

I just rebased Patrick's lock contention detection patch: https://review.whamcloud.com/#/c/fs/lustre-release/+/35287/.
We can use this patch to detect the lock contention on the OSS, and clients will be informed when the OST object is under lock contention.

Both client and server can determine to whether avoid lock expansion under lock contention.

Moreover, when the client was informed that the file is under contention, it can switch from default buffered I/O mode to direct I/O mode if the I/O size is large enough.