> Hello Joonwoo,
>
> Joonwoo Park:
> > While I'm examining udba=notify option, I encountered a behavior that
> > I didn't expect.
> > I have two directories (/tmp/tmpfs0 and /tmp/tmpfs1) which are
> > branches of /tmp/aufs0 as well asl /tmp/aufs1... which means two
> > different /tmp/aufs0 and /tmp/aufs1 are sharing same branches.
> > However if I add a same named file to /tmp/tmpfs1 and then
> > /tmp/tmpfs0, only /tmp/aufs0 shows updated file from /tmp/tmpfs0 while
> > /tmp/aufs1 still shows file from /tmp/tmpfs1
>
> Interesting use case.
> I have reproduced the problem. I'll dive into this problem when I have
> time.
> Thank you for reporting.
During the long long tests for next Monday release, I looked
2.6.33/fs/notify/fsnotify.c and might find the cause.
When aufs registers the callback to receive notify, fsnotify checks
whether the same callback is already registered or not. If it is already
registered, the new one is simply ignored. Finally two aufs-es receives
only one event. This is my current guess.
I know you are 2.6.32 instead of .33. But I also guess fsnotify may not
change so much in .33.
Anyway I will fix aufs, hopefully within this year.
Here are my current plans.
- make things to be registered to fsnotify per aufs super_block, so that
fsnotify will not handle these two callbacks are not identical (since
you have two aufs-es).
--> it consumes memory
or
- register only one callback to fsnotify. the handler in aufs
distributes for each aufs.
--> the handler operates several inodes in different aufs. I think
this is bad approach.
or
- ???
J. R. Okajima
------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
