Am Mittwoch, 11. Januar 2006 20:32 schrieb Josef Sipek: > > > > Do you plan to make this safely work in the future? > > We'd love to have it working, however there are other things that need to > be addressed first - the dentry/inode leak (I know there is at least one, > I'm trying to track it down, but it is reproduceable only by the BUG425 > test in rename-all.sh regression test.)
Sure, that's important to get the needed stability. Well, I think this feature would be very important to most users. Especially in combination with namespaces (consider a namespace with a fs mounted on /a and another namespace where /a is part (branch) of a unionfs-mount). This is a scenario not untypical to virtualization e.g. with VServer or OpenVZ. > > > And if not, why and > > where are the problems? > > As far as I know, the only problem is that each lower level file has its > own dentry and inode (yes, multiple files can share an inode, but that's > besides the point). When you access the union, what you are actually going > through are unionfs dentries and inodes which point to the lower dentries > and inodes. Now, the problem (at least to my undestanding) occurs when you > modify the lower file, which changes the lower dentry and inode, but the > changes aren't propagated to the unionfs dentries. Then when you access the > union again, it is possible that you'll get back stale information. ... that was my guess (fear) ... > > > > 1. remount the union (the better than #2) > > > > What happens in the time from altering the branch (which may take some > > time) until the remount takes place. Does this result in wrong metadata > > for the files, since metadata is taken only from the leftmost branch, and > > therefore an inconsistent view? > > Exactly. Whenever I speak remount, it is more of a unmount, change, mount. > Then a clean way would be: 1) make a snapshot/copy of the ro-branch 2) insert that snapshot/copy temporarily before the original ro-branch into the union 3) remove the original ro-branch 4) modify the original ro-branch directly 5) insert the originla ro-branch before the temporary ro-branch 6) remove the temporary ro-branch > > > 2. Increase the superblock generation number in unionfs (really a > > > hack): > > > > > > uniondbg -g /unionfs/mount/point > > > > sounds not to be safe? > > That, in essence, forces the VFS to consult us next time it tries to use > any unionfs dentry. The problem of course is the time between the lower > file change and when you run uniondbg. > > I hope this makes sense, Yes, thanks. > > Jeff. -- -- Wilhelm Meier email: [EMAIL PROTECTED] _______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
