On Monday 02 June 2008, hooanon05@yahoo.co.jp wrote:This is a very complicated approach, and I'm not sure if it even addresses the case where you have a shared mmap on both files. With VFS based union mounts, they share one inode, so you don't need to use idiotify in the first place, and it automatically works on shared mmaps. I mean having your own dentry and inode object is duplication. The underlying file system already has them, so if you have your own, you need to keep them synchronized. I guess that in order to do a lookup on a file, you need the steps of 1. lookup in aufs dentry cache -> fail 2. lookup in underlying dentry cache -> fail 3. try to read dentry from disk -> fail 4. repeat 2-3 until found, or arrive at lowest level 5. create an inode in memory for the lower file system 6. create dentry in memory on lower file system, pointing to that 7. create an aufs specific inode pointing to the underlying inode 8. create an aufs specific dentry object to point to that 9. create a struct inode representing the aufs inode 10. create another VFS dentry to point to that when you really should just return the dentry found by the lower file system. It's not so much a practical limitation as an exploitable feature. E.g. an unpriviledged user may use this to get an application into an error condition by asking for an invalid file name. Posix reserves a well-defined set of invalid file names, and deviation from this means that you are not compliant, and that in a potentially unexpected way. How does aufs know that one of its branches is an aufs itself? If you detect this, do you fold it into a single aufs instance with more branches? In case you don't do it, I don't see how you get around the stack overflow, but if you do it, you have again added a whole lot of complexity for something that should be trivial when done right. I personally think that a policy other than writing to the top is crazy enough, but randomly writing to multiple places is much worse, as it becomes unpredictable what the file system does, not just unexpected. Arnd <>< --
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Andrew Morton | -mm merge plans for 2.6.23 |
| James Bottomley | [Ksummit-2008-discuss] Fixing the Kernel Janitors project |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
git: | |
| Gerrit Renker | [PATCH 18/37] dccp: Support for Mandatory options |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | Re: [GIT]: Networking |
| Tantilov, Emil S | WARNING: at include/net/sock.h:417 udp_lib_unhash |
