Thank you for explaining the patch. It is nice to know a bit more about
aufs.
I applied this patch, and it appears to be working. The build software is no
longer reporting "text file busy". Do you think that this patch will make it
into the official AUFS tree ?
I will perform more testing and let you know what happens.
James
On Thu, Feb 4, 2016 at 11:28 PM, <[1]sf...@users.sourceforge.net> wrote:
James Burry:
> Here is the kernel message produced :
Thanx for the call trace.
Here is my current guess.
Brief scenario
- chmod sets "this file is being changed" mark to the file inode.
- exec(./a.sh) checks the mark, and rejects as "the file should not be
 changed during the execution."
Rather deep note
- chmod activates the aufs copy-up internally. the copied-up file, which
 is a newly created one on the upper writable branch, is opened with
 O_WRONLY flag. That is equivalent to set "this file is being changed"
 mark.
- The mark will be cleared when the file is closed, ie. when the copy-up
 is completed.
- But linux has a neat feature "delayed fput." It is a feature to
 postpone the closing file and to gain a better performance.
- As the mark is cleared when the file is closed, the mark remains until
 this neat feautre is activated.
- when exec(./a.sh) is issued, the mark MAY remains. In this case, the
 result will be ETXTBSY obviously.
This is just my guess, but here is a patch to force closing the file
after the internal copy-up. Would you apply it and test again?
J. R. Okajima
References
1. mailto:sf...@users.sourceforge.net
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
