Takanori Watanabe wrote: > In message <20041004053106.GQ88303_at_vertex.kz>, Boris Popov wrote: > >>On Sun, Oct 03, 2004 at 11:06:42PM +0200, Uwe Doering wrote: >> >>>>That isn't the issue. The issue is that an application might open >>>>the vnode in the unionfs mount, and another application might >>>>modify the same file in the underlying file system. If the kernel >>>>doesn't understand that it is really the same file, then cache >>>>incoherencies will occur. I'm actually not sure to what extent >>>>this is a problem already; John Heidemann's Phd thesis had a way >>>>of dealing with it, but FreeBSD doesn't do things that way AFAIK. >>> >>>Okay, but that's a different matter. What I was addressing at the start >>>of this discussion is an ambiguity issue with meta data, that is, >>>information that ends up in stat(2) and friends. >> >> Exactly, one never knows what parts of metadata used by applications. >>I can confirm that ino are ought to be unique inside filesystem, otherwise >>some programs will fail in a very obscure ways. > > Ok, the issue Uwe says is when underlying filesystem and > wrapping filesystem are diffent and if there are two files > with same identifier exists. > And the issue I want to fix is when underlying filesystem and > wrapping filesystem are same so getcwd routine failed to distinguish > the mount point. > > So it can be solved by translating fsid if the fsid of a file is same as > that of mountpoint. True? Correct. In this case the inode number is guaranteed to be unique. This might be okay as a local patch, but it is IMHO not a fix suited for FreeBSD in general. Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers gemini_at_geminix.org | http://www.escapebox.netReceived on Mon Oct 04 2004 - 04:26:19 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:15 UTC