more code paths, makes the code more complicated, not lighter. it might make a specific code path a little faster, but more chances for bugs.
On Thu, 2005-12-15 at 01:44 +0900, [EMAIL PROTECTED] wrote: > > O.k., I see the point. But: why does unionfs lookup a whiteout in a > > read-only > > branch? > > While I was thinking about Wilhelm's question, I've got an idea of new > option "dirs=<branch>=ro_wh". > Currently these options are 'ro' and 'rw'. A 'ro_wh' option is > perfectly equivalent to current 'ro'. But the meaning of 'ro' option > changes. In case of 'ro', unionfs does not lookup a whiteout entry, but > 'ro_wh' does. > Reducing the number of lookup will get a chance to make unionfs > lighter. I hope it will be effective to the simple cases, like tmpfs + > large cd/dvd image, tmpfs + readonly nfs, tmpfs + regular mntpnt and so > on. These cases will not need to modify the unionfs option. And I guess > that most users would use unionfs like this. > But it may not be effective in the complex cases, like the > branch is specified readonly currently but it had been writable, or it > is a writable branch of another unionfs. In these cases, user will need > to change the option from 'ro' to 'ro_wh', to keep on looking-up on the > readonly branch. > > I have once thought it doesn't need to lookup on the lowest branch only. > But now I think most readonly branch does not need to lookup whiteout, > and it is better to introduce a new option and make it choosable by > user. > > How do you think about changing the meaning of 'ro'? > all of users and > developers > If I write a patch, will it be merged? > > > Junjiro Okajima > _______________________________________________ > unionfs mailing list > [email protected] > http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs _______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
