On Tue, 2006-10-10 at 11:46 +0200, Jan Engelhardt wrote: > > > >unfortunately, it was never that stable and it performance sucked > >(basically only useful for append only things like log files). > > There is a problem (or advantage) with sparse copyup. Consider the > following action table (dirs=/B=rw:/A=ro): > > Current unionfs CVS > > Action | BRANCH A | BRANCH B | UNION VIEW > ------------------------------------+----------+----------+------------ > mount union | 0000 | - | 0000 > make changes to some range | 0000 | 0001 | 0001 > umount union | 0000 | 0001 | 0001 > make changes to the underlying file | 1000 | 0001 | 0001 > > 0 = some bytes filled with 0 > 1 = some bytes filled with 1 > - = sparse bytes > > With sparse copyup: > > Action | BRANCH A | BRANCH B | UNION VIEW > ------------------------------------+----------+----------+------------ > mount union | 0000 | - | 0000 > make changes to some range | 0000 | ---1 | 0001 > umount union | 0000 | ---1 | 0001 > make changes to the underlying file | 1000 | ---1 | 1001 > > 0001 vs 1001 - whoops! Though modifying underlying files is unsupported while > mounted, you see that this issue persists _across_ a not-mounted union.
yes, in my model, the backing store only was ever accessed via the union. It wasn't perfect, and I ended up deciding there were better ways to achieve what I wanted. _______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
