"Hans-Peter Jansen": > 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.
All the default values are described in manual, and I don't agree printing the default values under /sys/fs/aufs. As you know, the mount options in effect are printed in /proc/mounts, and generally people says it should not contain the default values. I don't know why you want to know the default values via /sys/fs/aufs. > 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. If vm_prfile is helpful for overlayfs or UnionMount, then I'd gladly post it to LKML. Actually it is useless for them because they don't implement their own file object. Here "file object" means a kernel internal object, so I try explaining in other example. Imagine you are developing something with object oriented language. There is a class called "file" and you create a sub class of it, eg. inheriting by "class sub_file : public file" or something. Then you can override every methods in the super class "file". Otherwise you have to use the original methods in "file". This relationship of super class and sub class is similar to VFS and every FS in linux. VFS (as a super class) declares struct file_operation and FS (as a sub class) implements it. The vm_prfile is something like for "sub_file" class. It never interact with the super class. overlayfs doesn't create "sub_file", no overriding ->mmap() either. It handles all files on its member directly. (Actually overlayfs overrides "directory" only for readdir operation.) There is no chance and space to set vm_prfile in overlayfs. Finally, in overlayfs, /proc/PID/maps and lsof(1) always print the path on its member. (Of course, it may not be important for some users) On the other hand, UnionMount doesn't create a sub class at all. Its path is always same (because it is not FS), which means vm_prfile is unnecessary and /proc/PID/maps and lsof(1) always print the expected correct path. 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
