"James .": > I do not specify any "xino" option in mount. According to man aufs, > xino is created on the first rw branch. I also have > /sys/fs/aufs/si_c30a7c19/xino.
OK. > To create files, I simply do "touch myfile", and I am not sure whether > it uses creat or link, however the file created is not a link of any > kind. I even do "echo aaaa > myfile", same result. OK. touch(1) and redirect issues creat/open(2) instead of link(2). > If you dont mind, could you please explain a little about the bugfix > on 20080929: > > - bugfix: under heavy load the dead inode might be re-used because of > the race condition between S_DEAD flag and some lock-free oprations. > force 'must-new' inode in some cases. > > Maybe there is a missing case that is not handled in au_new_inode with > regards to the must_new logic. Is there a test case that can cause > this bug to occur? When you unlink (or rename) a file, and last reference to the target inode becomes zero, it will be marked as S_DEAD and freed later. The marking and discarding the cached inode is done in VFS/dcache/icache layer instead of aufs. It means there exists a short time delay between the aufs deletion and VFS operation. If a process creates a file within this time range, aufs might assign the deleting inode for the new file. To reproduce the bug, I used to generate very heavy i/o load by 'racer.sh.' You may find it somewhere on the internet. The LTP testsuit may include it. If you try racer.sh, I'd suggest you to run it on the NFS-exported aufs, ie. on the nfs client, or aufs with NFS branches. These cases bring many work into aufs, and the time window may be extended a little bit and you will be subject to meet the problem. But, of course, it highly depends upon the timing. So you may need to test several hours. Finally, I may understand your problem. After your nautilus sets inotify for a directory, the dentry cache for the directory may be discarded. When a process access the dir and aufs lookup it, aufs is expecting the new inode for the dir. I am afraid this is wrong and aufs may get the remained inode for the dir, and should handle it correctly. Based on this guess, here is a patch. Won't you test it? J. R. Okajima
a.patch.bz2
Description: BZip2 compressed data
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
