Hello Junjiro, On Monday 04 July 2011, 16:32:20 sf...@users.sourceforge.net wrote: > "Hans-Peter Jansen": > > # grep -nr PROC_MAP . > > ./config.mk:24:CONFIG_AUFS_PROC_MAP = y > > In ./config.mk, one more PROC_MAP should appear. > Please apply this patch. > > It might be easier for you to get latest aufs source files.
FYI, the latest git release "2.1-standalone.tree-31-20110704" with the -DCONFIG_AUFS_FS_MODULE Makefile fix applied survived all tests so far, lsof behaves fine: COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME init 1 root cwd DIR 0,21 4096 2 / init 1 root rtd DIR 0,21 4096 2 / init 1 root txt REG 0,21 794912 12 /sbin/init init 1 root 10u FIFO 0,16 0t0 5841 /dev/initctl $ cat /sys/fs/aufs/config CONFIG_AUFS_FS=m CONFIG_AUFS_BRANCH_MAX_127=y CONFIG_AUFS_SBILIST=y CONFIG_AUFS_PROC_MAP=y CONFIG_AUFS_DEBUG=y An idea for the future: It would be really cool to introspect branch options in a /sys/fs/aufs/si_*/options file. I think, that your new approach to mmap is superior. Not only, that it got rid of the even more fragile fiddlings with vm_operations_struct, it seems less error prone. The additional patches to the kernel is worth it, IMHO. Hopefully, it's not getting too hard to maintain the vm_prfile field properly in the future.. For the time being, I couldn't be any happier with my current aufs 2.1 setup. I will try to trick it into issues for the next days, before rolling it out on the customers' site. Thanks for your formidable support, Junjiro. It's more than just appreciated. Pete ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2
