Hi, sometimes ago I posted a patch for a similar nfs-related situation. Ii is usable when the rightmost branch is nfs and ro. Lookups of whiteouts in the rightmost branches are suppressed with the patch. It was for unionfs-20051229-1859.
see: http://www.fsl.cs.sunysb.edu/pipermail/unionfs/2005-December/001564.html -- Wilhelm Am Freitag 14 April 2006 12:57 schrieb Kenneth Duda: > Consider this test script: > > mkdir a1 > mkdir a2 > mkdir a2/usr > mkdir a2/bin > mkdir ua > mount -t unionfs -o dirs=/tmp/a1=rw:/tmp/a2=ro none ua > exportfs -o rw,no_root_squash,async,insecure,fsid=44 127.0.0.1:/tmp/ua > mkdir nfs > mount -o tcp,nolock,actimeo=0 127.0.0.1:/tmp/ua nfs > mkdir b1 > mkdir ub > mount -t unionfs -o dirs=/tmp/b1=rw:/tmp/nfs=ro none ub > ls -l ub > > This script fails on the "ls" (unionfs 20060210, linux 2.6.14). It > lists "usr" and "bin" with lots of "???"'s on them, like this: > > # ls -l ub > total 0 > ?--------- ? ? ? ? ? bin > ?--------- ? ? ? ? ? usr > > The reason is that all NFS lookups fail. The reason for that is that > unionfs on the NFS client is doing NFS lookups of ".wh." files, and > unionfs on the NFS server is responding with EPERM, because unionfs is > understandably unfriendly about storing ".wh." files. Unionfs on the > client is unhappy about all the EPERMs checking for ".wh." files, and > passes the error along to stat. > > The very simple attached patch fixes the problem, changing things so > that a lookup of a ".wh." file returns ENOENT instead of EPERM. The > rationale for this is simple: a unionfs can never hold a ".wh." file > (because it uses that prefix internally) and therefore if you are > looking for one, it isn't there, so returning ENOENT is correct. (An > attempt to create a ".wh." file still returns EPERM). > > Now, why would one anyone ever want to create a union of an NFS-mount > of a union? Well... good question. But whatever the answer, now you > can! > > If anyone sees any problem with this patch, I'd appreciate it if you > could let me know. > > Thanks, > > -Ken _______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
