On 08/22/2010 11:34 AM, sf...@users.sourceforge.net wrote: > Lou Gosselin: > >> I'm speculating here: my guess is that the VMM is pointing to a struct >> inode which has been copied up by aufs into a new inode, but the VMM >> continues to refer to the old one. The new and old struct inode continue >> to share i_ino #. If this is the case, would it be possible to assign >> the old inode struct a new unique i_ino? >> >> The rational being that the # should be unique per device, and the old >> struct inode is never accessed using the old # anyways. (The old struct >> is never accessed at all outside of mmap, which continues to use it's >> pointer). The unique inode number would solve the current ambiguity. >> > Interesting. > It will be difficult but worth to consider. > In remount-phase, aufs may be able to unhash the cached dentries > (inodes). If this unhashing is done in safe, then VFS will ignore the > unhashed dentry and next lookup will not re-use the cached one. It means > a new dentry/inode will be created (not shared) and a new inum will be > assigned. > There are many places in kernel to test whether a dentry is unhashed or > not, I am afraid we (or only I) have to check all d_unhashed() calls. > Also it will cost high since the unhashed dentry/inode are still in > memory but they will not be re-used. > A bit foreign to me, but maybe I can try and give it a shot if I get time. It is not a high priority though. It still requires aufs to output an inode list per branch.
Lou Gosselin ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
