[LU-19600] Potential future conflict between fsync and layout operations (e.g., restriping, mirroring)

• Type: Improvement
• Resolution: Unresolved
• Priority: Medium
• Fix Version/s: Lustre 2.18.0
• Affects Version/s: Lustre 2.17.0
• Severity: 3
• Assignee: WC Triage
• Reporter: Artem Blagodarenko

Description

Currently, fsync operations do not acquire layout locks because:

1. fsync only flushes already-mapped pages to disk.
2. The mapping from file offsets to OST objects occurs during write operations.
3. Layout changes should only affect new writes, not existing cached data.
4. Acquiring layout locks during fsync can cause deadlocks when fsync is called from within write operations (see EX-12989).

However, as noted by green, this assumption may not hold in the future. When more advanced features such as smart mirroring or on-the-fly restriping (e.g., when an OST runs out of space) are introduced, fsync may need to interact with layout locks differently.
Running fsync concurrently with layout-changing operations could lead to data consistency issues or race conditions.

Issue Links

• is related to: LU-19556 fsync() does not need to wait for layout flush