[LU-10885] enable flock by default

• Type: Improvement
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.13.0, Lustre 2.12.3, Lustre 2.16.0
• Labels: easy
• Assignee: Patrick Farrell (Inactive)
• Reporter: Andreas Dilger

Description

We should consider to enable the flock mount option by default, while still allowing localflock and noflock options for users that do not want this functionality.  From looking at issues reported on http://stackexchange.com/ and others, it seems that the lack of flock functionality by default is an obstacle for many users to use databases on top of Lustre.

If the users are not using flock functionality, I don't think this adds any overhead, and if they are using this functionality then they want it enabled in any case.

Issue Links

• is related to: LU-8069 Allow remount to include "flock" and "localflock", as well as "lazystatfs" and "nolazystatfs"
• is related to: LU-12348 "flock" mount option should be enable by default

Comments

[Gerrit Updater]

"Oleg Drokin <[e-mail]>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/51948/
Subject: LU-10885 docs: note flock now being enabled by default
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: b557fb21c8dfa676fd4ec528fed3d8ea17bc665f

[Gerrit Updater]

"Laura Hild <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/51948
Subject: LU-10885 docs: note flock now being enabled by default
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 10701dd9101831bbe9521705d2a3754560eaa920

[Patrick Farrell (Inactive)]

Thank you for pointing out the wiki - I've updated it to give users a strong push towards 'flock'.  (localflock has always seemed like a way for ambitious users to corrupt their data)

One note: I don't actually know when we switched from whatever flock implementation had a performance cost, but it was a long time ago, so I just settled on "2.x is fine".  (It's definitely true of 2.4/2.5, as well as at least the Seagate 2.1, so I'm pretty sure it's correct.)

[Aurelien Degremont (Inactive)]

Thanks a lot for the explanations!

[Andreas Dilger]

The flock locks are implemented via DLM on the MDS, but in a separate lock namespace from IBITS locks used for regular files. They are only used of flock is requested by the application, so should have no impact if the application is not using this feature.

[Patrick Farrell (Inactive)]

Correct - flock is an independent type of MDT lock (it's sort of like if there was a flock bit in the IBITS bit set, but it's not implemented that way), and flocks only interact with other flocks.  So only for those users.  They don't interact at all with other locks - Don't conflict, etc.

I'll see if I can still edit the wiki.

[Aurelien Degremont (Inactive)]

Here is the page: http://wiki.lustre.org/Mounting_a_Lustre_File_System_on_Client_Nodes

Probably better you fix it with the wording you think is appropriate.

 

For my own knowledge, I've never looked at how flock is implemented, but enabling flock does not change at all how locking is working for any other Lustre resources? This only has impact for users explicitly calling flock on their files?

[Patrick Farrell (Inactive)]

Oh, jeez - I'm not sure when that was written, but it's completely wrong.  It has no measurable impact on performance at all, unless you've got an app that ends up contending those locks between nodes, in which case it is asking for mutual exclusion, and we are only following its requests.  The only case where you'd see a performance hit is in the case of an app making heavy use of locks it doesn't need.  (I am not considering the case where the app makes heavy use of the locks for good reason.  In that case, it needs them for correct operation.)

degremoa, can you link the wiki page or clean it up yourself?  It's just totally wrong.

[Aurelien Degremont (Inactive)]

How this fit with this paragraph from Lustre wiki:

flock: enable support for cluster-wide, coherent file locks. Must be applied to the mount commands for all clients that will be accessing common data requiring lock functionality. Cluster-wide locking will have a detrimental impact on file system performance, and should only be enabled when absolutely required. For some applications, the locking is only necessary on a sub-set of nodes. For example, the CTDB cluster framework used by Samba to provide a parallel, high-availability SMB gateway, relies on locking of a shared file when coordinating cluster start-up and recovery. However, only the CTDB nodes need to mount the Lustre file system with the flock option. This is an example of application or domain-specific lock requirements.

If you really think there is very limited performance impact, we should probably revise this wiki page.

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/34987/
Subject: LU-10885 llite: enable flock mount option by default
Project: fs/lustre-release
Branch: b2_12
Current Patch Set:
Commit: 16fb13eb386380a4eb46b7e016a66cb38a01f54f