Proposal for a new I/O library design
Mon, 28 Jul 2003 18:28:30 -0700 (PDT)
On Tue, 29 Jul 2003, Alastair Reid wrote:
> Ben Rudiak-Gould wrote:
> > If it's not possible to provide a guarantee of File identity then we
> > should probably drop the whole idea of File values.
> I haven't been following in enough detail to know if File values are a good
> idea or not but it's maybe worth mentioning that if you're NFS, there's no
> way to test file identity. IIRC, the problem is that a machine might
> nfs-export overlapping parts of its filesystem so you might have two names
> for the same file.
I don't think this is fatal. The important part of File identity is that
two File values which compare equal necessarily denote the same file, not
the converse. I don't think there's any observable difference between File
values which denote different files and File values which denote the same
file but don't compare equal, since there could be a demon (not daemon --
I'm thinking Maxwell's demon here) watching everything you do to file x/y
and immediately doing the same thing to file y/x.
Now, if NFS doesn't even guarantee the forward implication (for e.g.
filehandle comparison by value), then that's bad. But not bad for us. Bad
for anyone foolish enough to use NFS.
> ps (At least in FreeBSD) mmapping an NFS-mounted file can also lead to
> unhappiness. If you mmap the same NFS-mounted file multiple times, you can
> end up with multiple copies of the same page which leads to chaos when you
> start writing to the pages.
That's bad too. See previous paragraph. :-)