Hi, "Hans-Peter Jansen": > 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:
Thanks for your repeated builds and tests. I am glad aufs satisfies you again. > An idea for the future: > It would be really cool to introspect branch options in a > /sys/fs/aufs/si_*/options file. What is branch options? "=ro", "=rw" etc.? If so, it is printed in /sys/fs/aufs/si_*/brN. > 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.. Agreed. What I am afraid is, - People doesn't like changing mainline source files. So aufs kept the "no changes except EXPORT_SYMBOL" policy. This "vm_prfile" patch breaks it. - In every mainline upgrade, I have to check the changes around vm_file. - If aufs user's kernel is patched by distributor or something and it changes something around vmfile, then a problem may happen. In this case, disabling CONFIG_AUFS_PROC_MAP should solve the problem, but /proc/PID/maps will show the branch path. > 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. I'd suggest you to wait until next release since I am still testing. J. R. Okajima ------------------------------------------------------------------------------ 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
