Wilhelm Meier: > The top layer unionfs would then lookup whiteouts with prefix .wh.<fsid1>. > and > the lower layer would use whiteouts with prefix .wh.<fsid2>., but would not > block the lookup or creation with a prefix .wh.<fsid1>. > So the whiteouts for each layer of all the unionfs in the stack are > seperated. > I hope it was clearer now.
I see. It must be useful to you. It is a good idea. I think it should be called whiteout prefix option, in stead of fsid option. But it needs to be very careful to use it. For example, - on nfs server, /unionfs = /rw + /ro and export it as writable. fsid=<server> - on nfs client, mount it as writable and make unionfs. fsid=<clientA> - on nfs client, remove a 'file', which create server:/rw/.wh.clientA.file - on another nfs client, mount it as writable too. fsid=<clientB> - on clientB, you can see '.wh.clientA.file' and 'file'. Removing .wh.clientA.file, unionfs creates server:/rw/.wh.clientB..wh.clientA.file - on clientA, you can see both of the original 'file' and '.wh.clientB...' Finally, fsid option will conflict a writable unionfs-ed nfs share and general nfs semantics. And it is needed to consider/design useing with delete=whiteout option, and the case when the client does not use fsid option while the server use it. It might be a unionfs general problem of 'which branch we should process?' (I hope you have ever read my rename2.patch) In this case, I think it is better to use unionfs on nfs clinet only, without fsid option. I mean stop nesting. Junjiro Okajima _______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
