[LU-8441] Text file busy error after overwriting file

• Type: Bug
• Resolution: Duplicate
• Priority: Minor
• Affects Version/s: Lustre 2.8.0, Lustre 2.5.5
• Labels: llnl llnlfixready
• Environment: lustre-2.5.5-6chaos_2.6.32_573.26.1.1chaos.ch5.4.x86_64.x86_64
• Severity: 3
• Assignee: Jian Yu
• Reporter: Teresa Kamakea (Inactive)

Description

Here's our reproducer:

sh -c 'cd /p/lscratchd/$USER && (f=toss-3321; rm -f $f; cp /bin/ls $f; od -N1 $f; ./$f; echo > $f; rm -f $f)'

This looks similiar to LU-6232. This affects emacs which is impacting our users. This behaviour is a difference in how xemacs vs. vi deal with files that they already have open. With vi, it always writes to a temporary new file which it then moves over top of the file being edited. With xemacs, the original file is moved to <file>~ and a new file written on the first write. After that it overwrites the new file. One can see this by running them, saving a file, checking the inode number with "ls -i <file>", and then repeating the save and check operations. With xemacs the inode number won't change for each save. With vi, it will.

Issue Links

• duplicates: LU-8019 Openlock breakage
• is duplicated by: LU-7727 open with FMODE_EXEC fails with ETXTBSY after a failed FMODE_WRITE open attempt on a read only client

Comments

[Jian Yu]

Thank you, Olaf. I'm closing this ticket as a duplicate of LU-8019.

[Olaf Faaland]

Thanks, Jian and Oleg.

That's all LLNL needs for this. You can close notfix (or whatever your normal process is).

[Oleg Drokin]

This is mostly due to lingering file opens for write that got cached on the client. So when the exec comes it sees the file is opened for write and bails out (server side). We tried to just obtain a necessary ldlm lock before opening, but that proved to be very expensive.

The cached open on the other hand is the real problem here, originally mostly aimed at nfs opened files, it managed to be enabled for other types of opens at times leading to such problems.

[Jian Yu]

Hi Olaf,
According to debug logs, there were some analyses in the previous comment https://jira.hpdd.intel.com/browse/LU-8441?focusedCommentId=205806&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-205806 about where the ETXTBSY is coming from.

Hi Oleg,
About the factors that lead to the issue, could you please give some hints? Thank you.

[Olaf Faaland]

Hi Jian and Oleg,

Thank you for investigating. Given the complexity and risk we can close this notfix and we will do the same in our local ticket.

For my education, can you tell me where the EBUSY is coming from in our broken case, and describe of some of the factors that lead to this? It need not be a complete and perfect description, just some hints that help understand the relevant code paths.

[Jian Yu]

Hi Olaf,
The fix is LU-8019 and the prior patches. While trying to back-port the patch, I found it had a long dependency chain, including those for LU-3544, which contains more patches.