Prasad Koya:
> Okajima,=0A=0AI see that aufs 2.2 just prints the warning and continues.=A0=
> =0A=0A=0AWhat are the effects of this cache inconsistency ie., inode of auf=
> s isn't consistent with inode of branch. When would aufs again sync with br=
> anch's inode? What happens if someone deletes the file directly on branch? =
> Does it mean that aufs thinks that file is there (because it wasn't notifie=
> d) but file is gone from underneath? Sounds like "ubda=3Dnotify" is a must-=
> have option so aufs works correctly. Please correct me if I'm wrong.=A0=0A=
> =0Athank you.=0A=0A/* successful returns with iinfo write_locked */=0A/* to=
> do: return with unlocked? */=0Astruct inode *au_new_inode(struct dentry *de=
> ntry, int must_new)=0A{=0A:=0A=A0 =A0 =A0 =A0 }=0A=0A=A0 =A0 =A0 =A0 if (un=
> likely(au_test_fs_unique_ino(h_dentry->d_inode)))=0A=A0 =A0 =A0 =A0 =A0 =A0=
> =A0 =A0 AuWarn1("Warning: Un-notified UDBA or repeatedly renamed dir,"=0A=
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 " b%d, %s, %.*s, hi%lu, i%l=
> u.\n",=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bstart, au_sbtype(=
> h_dentry->d_sb), AuDLNPair(dentry),=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
> =A0 =A0 =A0 (unsigned long)h_ino, (unsigned long)ino);=0A=A0 =A0 =A0 =A0 in=
> o =3D 0;=0A=A0 =A0 =A0 =A0 err =3D au_xino_write(sb, bstart, h_ino, /*ino*/=
> 0);=0A=A0 =A0 =A0 =A0 if (!err) {=0A=0A=0A=0A=0A=0A=0A_____________________=
> ___________=0AFrom: "sf...@users.sourceforge.net" <sfjro@users.sourceforge.=
Generally aufs can continue working when you modify files on branch
directly (bypassing aufs). But sometimes it is impossible. For such
case, aure returns EIO.
If it is recoverable, aufs does it and continue working. It is done at
the time of "revalidating dentry".
If you delete a file on branch directly and then try accessing via aufs,
aufs generally detects it and return an error. But in some complicated
situations, the behaviour may be different from your expectations.
"udba=notify" is surely important option, but I don't know it is
"must-have" for all users. Users can choose prohibiting the direct
modification on branch.
See the aufs manual in detail.
(from the manual)
----------------------------------------------------------------------
.SH User's Direct Branch Access (UDBA)
UDBA means a modification to a branch filesystem manually or directly,
e.g. bypassing aufs.
While aufs is designed and implemented to be safe after UDBA,
it can make yourself and your aufs confused. And some information like
aufs inode will be incorrect.
For example, if you rename a file on a branch directly, the file on
aufs may
or may not be accessible through both of old and new name.
Because aufs caches various information about the files on
branches. And the cache still remains after UDBA.
Aufs has a mount option named `udba' which specifies the test level at
access time whether UDBA was happened or not.
.
.TP
.B udba=none
Aufs trusts the dentry and the inode cache on the system, and never
test about UDBA. With this option, aufs runs fastest, but it may show
you incorrect data.
Additionally, if you often modify a branch
directly, aufs will not be able to trace the changes of inodes on the
branch. It can be a cause of wrong behaviour, deadlock or anything else.
It is recommended to use this option only when you are sure that
nobody access a file on a branch.
It might be difficult for you to achieve real `no UDBA' world when you
cannot stop your users doing `find / \-ls' or something.
If you really want to forbid all of your users to UDBA, here is a trick
for it.
With this trick, users cannot see the
branches directly and aufs runs with no problem, except `auplink' utility.
But if you are not familiar with aufs, this trick may make
yourself confused.
.nf
# d=/tmp/.aufs.hide
# mkdir $d
# for i in $branches_you_want_to_hide
> do
> mount -n --bind $d $i
> done
.fi
When you unmount the aufs, delete/modify the branch by remount, or you
want to show the hidden branches again, unmount the bound
/tmp/.aufs.hide.
.nf
# umount -n $branches_you_want_to_unbound
.fi
If you use FUSE filesystem as an aufs branch which supports hardlink,
you should not set this option, since FUSE makes inode objects for
each hardlinks (at least in linux\-2.6.23). When your FUSE filesystem
maintains them at link/unlinking, it is equivalent
to `direct branch access' for aufs.
.
.TP
.B udba=reval
Aufs tests only the existence of the file which existed. If
the existed file was removed on the branch directly, aufs
discard the cache about the file and
re-lookup it. So the data will be updated.
This test is at minimum level to keep the performance and ensure the
existence of a file.
This is default and aufs runs still fast.
This rule leads to some unexpected situation, but I hope it is
harmless. Those are totally depends upon cache. Here are just a few
examples.
.
.RS
.Bu
If the file is cached as negative or
not-existed, aufs does not test it. And the file is still handled as
negative after a user created the file on a branch directly. If the
file is not cached, aufs will lookup normally and find the file.
.
.Bu
When the file is cached as positive or existed, and a user created the
same named file directly on the upper branch. Aufs detects the cached
inode of the file is still existing and will show you the old (cached)
file which is on the lower branch.
.
.Bu
When the file is cached as positive or existed, and a user renamed the
file by rename(2) directly. Aufs detects the inode of the file is
still existing. You may or may not see both of the old and new files.
Todo: If aufs also tests the name, we can detect this case.
.RE
If your outer modification (UDBA) is rare and you can ignore the
temporary and minor differences between virtual aufs world and real
branch filesystem, then try this mount option.
.
.TP
.B udba=notify
Aufs sets either `fsnotify' or `inotify' to all the accessed directories on its
branches
and receives the event about the dir and its children. It consumes
resources, cpu and memory. And I am afraid that the performance will be
hurt, but it is most strict test level.
There are some limitations of linux inotify, see also Inotify
Limitation.
So it is recommended to leave udba default option usually, and set it
to notify by remount when you need it.
When a user accesses the file which was notified UDBA before, the cached data
about the file will be discarded and aufs re-lookup it. So the data will
be updated.
When an error condition occurs between UDBA and aufs operation, aufs
will return an error, including EIO.
To use this option, you need to enable CONFIG_INOTIFY and
CONFIG_AUFS_HINOTIFY.
In linux-2.6.31, CONFIG_FSNOTIFY was introduced and CONFIG_INOTIFY was
listed in Documentation/feature-removal-schedule.txt. In aufs2-31 and
later (until CONFIG_INOTIFY is removed actually), you can choose either
`fsnotify' or `inotify' in configuration. Whichever you choose, specify
`udba=notify', and aufs interprets it as an abstract name.
To rename/rmdir a directory on a branch directory may reveal the same named
directory on the lower branch. Aufs tries re-lookuping the renamed
directory and the revealed directory and assigning different inode
number to them. But the inode number including their children can be a
problem. The inode numbers will be changed silently, and
aufs may produce a warning. If you rename a directory repeatedly and
reveal/hide the lower directory, then aufs may confuse their inode
numbers too. It depends upon the system cache.
When you make a directory in aufs and mount other filesystem on it,
the directory in aufs cannot be removed expectedly because it is a
mount point. But the same named directory on the writable branch can
be removed, if someone wants. It is just an empty directory, instead
of a mount point.
Aufs cannot stop such direct rmdir, but produces a warning about it.
If the pseudo-linked file is hardlinked or unlinked on the branch
directly, its inode link count in aufs may be incorrect. It is
recommended to flush the pseudo-links by auplink script.
----------------------------------------------------------------------
J. R. Okajima
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
