David Schultz wrote: > On Mon, Oct 04, 2004, Takanori Watanabe wrote: > >>>With 'unionfs' you can have underlying files from two different layers >>>(upper and lower) on two different file systems which may, by >>>coincidence, have the same inode number. Now, if you override the real >>>va_fsid with that of the 'unionfs' mount you'll end up with two >>>'unionfs' vnodes that appear to represent the same file (a hard link, >>>for instance), but in reality the files are different entities. >>>Obviously, both the kernel and applications might draw wrong conclusions >>>in this case. >> >>I think the three filesystem entry >>1. upper layer file >>2. lower layer file >>3. unionfs file >>can be treated as different. > > I didn't pursue this before because I was concerned that it would > introduce cache consistency issues between the union vnode and the > underlying vnode. But I guess all vnops ultimately wind up at the > underlying vnode, so this hopefully isn't an issue... Applications use the synthesized unionfs vnodes. They have no knowledge of what's going on underneath. So they can't tell whether one unionfs vnode refers to a file in the upper layer, and the other to one in the lower layer. In case of a stat(2), for instance, if va_fsid is to be overridden by the va_fsid of the unionfs' mount, unionfs would need to generate and manage its own (unique) file numbers as well, instead of passing va_fileid of the underlying layer unchanged. Otherwise you get the ambiguity I pointed out. Uwe -- Uwe Doering gemini_at_geminix.org
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:15 UTC