On Thu, 2008-01-17 at 10:56 -0500, Gregory Haskins wrote: > Paul Albrecht wrote: > > On Wed, 2008-01-16 at 18:27 -0500, Gregory Haskins wrote: > > > >> Erez Zadok wrote: > >> > >>> [I recommend we direct future discussions in this thread to the unionfs > >>> ML. -ezk] > >>> > >> (Note I am not subscribed to unionfs ML, so please include me in CC) > >> > >> > >>> Paul, you're looking into a specific 2-branch configuration where one > >>> branch > >>> is r-o and the other is r-w. Yes, in that specific case, one could argue > >>> that a whiteout isn't needed. But what if I have N branches, with a mix > >>> of > >>> rw/ro branches, where a file or its whiteout could exist in any branch? > >>> If > >>> I don't create a whiteout, then I have to scan all N branches and remove > >>> the > >>> same file from there (assuming the file doesn't exist on a r-o branch -- > >>> then I have to abort). > >>> > >> I wonder if there is a way to track which files were created in a branch > >> vs promoted to a branch? If so, wouldn't only files in the promoted > >> class then require a whiteout file? I have no idea if this is plausible > >> with the unionfs architecture, but it would address Paul's concern. > >> > >> For instance, what if you created a shadow/hidden ".cow" file when this > >> promotion occurs, and then rename it to the whiteout file if it gets > >> deleted. Files without a .cow shadow file simply get deleted without > >> any extra action. Files with a .cow shadow file delete the local branch > >> copy and rename the .cow to the whiteout. > >> > >> > > > > The problem with this approach is it pollutes the name space of the cow > > layer with a bunch of hidden files that really aren't needed which is > > what I was objecting to in the first place. > > > > Hmm..yes. The problem is always going to be "metadata tracking" vs > "n-branch searching" I guess. Perhaps it could be a knob to select > n-branch searching, with the default for N=2 is on, and its off for N>2. >
Don't think it matters how may branches comprise a union mount. If a file is created in a cow layer of the mount, that is, it's not copied up from a read only branch, then the union file system absolutely should not use whiteout because it doesn't make any sense. There's no point in using the whiteout to cover-up a file which doesn't exist in the union mount at the time the file is deleted. If it is objected that a branch may be subsequently inserted containing a file with the same name as the "deleted" file which will show through and this is counter to a user's expectations, then I would simply point out that this is not at all intuitive and only a developer as opposed to a user would make this argument. Lastly, I guess I don't really care how this is implemented, however, it's not obvious to me why "n-branch searching" can't be done efficiently. > > Checking the lower layers of the union mount for the file name to > > determine whether the whiteout is required seems to make more sense, > > that is, if the file exists in lower layers generate a whiteout in the > > cow layer otherwise simply delete the file. > > > > > >> Just a thought. > >> > >> Regards, > >> -Greg > >> > >> > > -- Paul Albrecht _______________________________________________ unionfs mailing list: http://unionfs.filesystems.org/ unionfs@mail.fsl.cs.sunysb.edu http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
