Hello Pip,
I am still considering how to support atomic_open(), but all of my
approach are not good. And I am start thinking that your approach is
better eventually.
Here is what I thought. If you have any comment, please let me know.
Support for a branch who has its ->atomic_open()
----------------------------------------------------------------------
The filesystems who implement its ->atomic_open() are not majority, but
surely exist. For example NFSv4 does, and aufs should call NFSv4
->atomic_open, particularly for open(O_CREAT|O_EXCL, 0400). Other than
->atomic_open(), NFSv4 returns an error for this case. While I am not
sure whether all filesystems who have ->atomic_open() behave like this,
but NFSv4 surely return an error.
Generally speaking, calling ->atomic_open() is less important for other
open(2) cases.
In order to support ->atomic_open() for aufs, there are a few
approaches.
A. Introduce aufs_atomic_open()
- calls one of VFS:do_last(), lookup_open() or atomic_open() for
branch fs.
B. Introduce aufs_atomic_open() calling create, open and chmod, an aufs
user Pip Cet's approach
- calls aufs_create(), VFS finish_open() and notify_change().
- pass fake-mode to finish_open(), and then correct the mode by
notify_change().
C. Extend aufs_open() to call branch fs's ->atomic_open()
- no aufs_atomic_open().
- aufs_lookup() registers the TID to an internal object.
- aufs_create() does nothing when the matching TID is registered, but
registers the mode.
- aufs_open() calls branch fs's ->atomic_open() when the matching
TID is registered.
D. Extend aufs_open() to re-try branch fs's ->open() with superuser's
credential
- no aufs_atomic_open().
- aufs_create() registers the TID to an internal object. this info
represents "this process created this file just now."
- when aufs gets EACCES from branch fs's ->open(), then confirm the
registered TID and re-try open() with superuser's credential.
Pros and cons for each approach.
A.
- straightforward but highly depends upon VFS internal.
- the atomic behavaiour is kept.
- some of parameters such as nameidata are hard to reproduce for
branch fs.
- large overhead.
B.
- easy to implement.
- the atomic behavaiour is lost.
C.
- the atomic behavaiour is kept.
- dirty and tricky.
- VFS checks whether the file is created correctly after calling
->create(), which means this approach doesn't work.
D.
- easy to implement.
- the atomic behavaiour is lost.
- to open a file with superuser's credential and give it to a user
process is a bad idea, since the file object keeps the credential
in it. It may affect LSM or something. This approach doesn't work
either.
J. R. Okajima
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
