I don't know yet much about the implementation details of unionfs, but it sounds to a me as a general problem which arises if one tries to stack union-fs together. The problem is the fixed prefix in the name-schema for the whiteouts. If the prefix would be .wh.<fsid>. with <fsid> some sort of identifier which must be unique in the stack of filesystems, then the problem could be solved. Whiteout-names with the prefix .wh.1234. would be rejected of the unionfs-layer with the fsid=1234 returning EPERM, whereas a whiteout from the layer above with e.g. the fsid=5678 could be written.
Could this be a solution? This would correspond to an option fsid=nnnn similar to NFS. Am Mittwoch, 14. Dezember 2005 17:44 schrieb [EMAIL PROTECTED]: > > 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 -- -- Wilhelm Meier email: [EMAIL PROTECTED] _______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
