On Tuesday 05 July 2011, 09:15:36 sf...@users.sourceforge.net wrote: > 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 thought of current options, that aren't related to: brN and xi_path, e.g. the (default) setting of all flags: udba=none | reval | notify plink | noplink ... It would be handy to check the current active settings. Together with the man page, it would be easy to check, if some different settings improve the situation. > > 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. It's probably time to discuss this on LKML. Sure, aufs is rejected, but the mmap issue is real for a number of projects. If we find a consensus about the infrastructure, it should be possible to find a way to make it palatable for the core people. A first possible step would be publishing your patch with the mm people, Miklos, Al and hch cc'ed as a RFC, while making clear, that it's not meant for mainline, but just to discuss the needs for memory mapped files in layered filesystems. I can help you phrasing the mail, if you like. > - 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. Yes, that's an issue. OTOH, given that your patch applied cleanly on the SuSE kernel is a good sign. Traditionally, they do heavy kernel patching (remember the vm_operations_struct issue). > > 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. Fine with me. Thanks again, 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
