On Wed, Jan 11, 2006 at 01:44:51PM +0100, Wilhelm Meier wrote: > > On Thu, Jan 05, 2006 at 04:13:31AM -0500, Art Wallace wrote: > >> I'm a new unionfs user and have some basic questions to ask. > >> > >> First off, I want to be sure that what I'm doing is safe. I have > several hard disks which are currently shared as read/write samba > shares. Now with unionfs, I've combined these hard disks into one > read/only directory for convenient browsing purposes. The unionfs dir > is shared as a read/only samba share. What I want to know is whether or > not it is safe to modify the "source" directories by accessing them > from their read/write samba shares. My tests show this working, as the > unionfs dir/share is picking up the changes made to the contents of the > original directories. But will this cause problems? > > > > With the way things are done now, it is not safe. You can do two things > right now: > > 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.) > 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. > > > > 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. > > 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, Jeff. _______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
