Wojciech Kocjan: > I did make a quick check and it is not possible to have ext* > filesystem - the inode is kept in use as number of references to the > file is >0. I tried creating files until I ran out of inodes, but same > inode was never reused (I just wanted to be sure this is aufs > specific). So I think this is the problem.
No. The problem is not how aufs assigns the inode number. It is the lifetime of "file" object in kernel. First of all, here are the general rules. - when you open a file (on disk), kernel creates a "file" object in memory and sets its reference counter to 1. - when you close the file, the ref counter is decremented and when it reaches zero, the "file" object is destroyed and freed. - if you mmap() the file, it increments the ref counter and the "file" object is not freed even if you close() it. This situation is kept until you unmap() it. Now the problematic aufs3-proc_map.patch comes. As you might know, every /proc/PID/maps (and others including lsof(1)) shows the mmapped file path. But the showed file path is branch's instead of aufs's. aufs3-proc_map.patch solves this problem, and applying it /proc/PID/maps and lsof(1) shows the path in aufs expectedly and correctly. The patch operates two internal "file" objects, particulary on their ref counter. One is aufs's and the other is branch's. I think this is the source of our current problem. Ubuntu doesn't apply aufs3-proc_map.patch, but I always apply it (and enable CONFIG_AUFS_PROC_MAP). I have to confess that I didn't test aufs _without_ aufs3-proc_map.patch. With the patch, aufs works correctly. That is the reason I could not reproduce the problem on my test machine. Now your test program succeeds on my ubuntu machine with appllying aufs3-proc_map.patch. The purpose of aufs3-proc_map.patch is to change only the shown path in /proc/PID/maps. So this is a problem of aufs definitly. I will try fixing this bug as soon as possible, but I am going to be busy and it may take some time. So the first and simplest solution for you is to ask ubuntu people to apply aufs3-proc_map.patch, if they don't have any objection. Of course you can do it by yourself for your kernel. Last but not least, thank you for the bug report and for your repeated tests. I believe it irritated you and took much time. J. R. Okajima ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
