Hi, Thanks for the very good explanation :) I now understand the issue better.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1243591 I have also submitted a bug against Ubuntu. However, I noticed that the instructions on your website do not explicitly require the patch - i.e. "- apply ./aufs3-proc_map.patch too, if you want to make /proc/PID/maps (and others including lsof(1)) show the file path on aufs instead of the path on the branch fs." I am not sure if you should make it more explicit that aufs is tested only/mainly with this patch applied as well? 2013/10/19 <sf...@users.sourceforge.net>: > > Wojciech Kocjan: >> Ok, I have read the patch (not much of a kernel dev, but can >> understand more or less what happens I think) - with the patch, the >> inode is copied from original file? Or is it only shown in >> /proc/*/maps? And if this patch is not applied, what is the inode set >> to? Or perhaps I am not understanding this at all? - it is possible, >> to be honest :-) > > The patch changes the "file" object instead of inode. The key object > when /proc/PID/maps prints the file path is "file" object. > And "file" object refers brabra object, and brabra object refers the > inode. So the incorrect ref counter affects the lifetime of inode. Too > early destruction of the inode is the cause of re-using the inode number. > > >> I am simply trying to understand why applying this patch would resolve >> the issue. > > Please don't forget enabling CONFIG_AUFS_PROC_MAP. > > On my side, I've found the problem is around CONFIG_AUFS_PROC_MAP > strictly. > > > 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=60135991&iu=/4140/ostg.clktrk
