[LU-13319] "lfs mirror extend" returns EBUSY for open files Created: 03/Mar/20  Updated: 15/Dec/23

Status: Open
Project: Lustre
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Andreas Dilger Assignee: WC Triage
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Related
Severity: 3
Rank (Obsolete): 9223372036854775807

 Description   

If a file is still open at the time that "lfs mirror extend" is called, regardless of whether it is open for read or write, then EBUSY is returned.

It should be possible to create a mirror on a file open for reads, and in theory also for files open for writes if there are not actively being modified. Otherwise, it is possible for a long-running process would block a file from being mirrored.



 Comments   
Comment by Andreas Dilger [ 03/Mar/20 ]

Alex, can you please fill in the details here - commands run, maybe client/server debug logs if this is unique to your system.

Comment by Andreas Dilger [ 15/Dec/23 ]

Alex, I thought that we fixed this issue for at least files opened read-only?

In theory, it should also be possible to create a mirror on a file opened for write, as long as it is not actually modified while the mirror is being created. However, there may be complexity due to the FLR handling of marking the mirror with LCME_FL_STALE when the file is modified. However, it should be possible (and relatively easy?) to attach a mirror with LCME_FL_STALE right from the beginning if the file data version has changed since the mirror copy started.

That would not result in a completely uptodate mirror copy, but at least provides a mostly good copy of the file, and if files are kept open for a long time it would allow the initial (stale) mirror to be created and then it could be periodically resync'd with more uptodate information. This is still valuable for cases where FLR is used as a redundancy mechanism in case the primary copy of the file is lost, and having a copy that is e.g. 1h old is better than not having a copy of the file at all.

Generated at Sat Feb 10 03:00:16 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.