|
Joseph Mack wrote:
>
> Hi Dave,
>
> One of the problems with running NFS as an LVS'ed service (ie to
> make an LVS fileserver), that has come up on this mailing list is that a
> filehandle is generated from disk geometry and file location data. In
> general then the identical copies of the same file that are on different
> real-servers will have different file handles. When a real-server is
> failed out (e.g. for maintenance) and the client is swapped over to a new
> machine (which he is not supposed to be able to detect), he will now have
> an invalid file handle.
>
> Is our understanding of the matter correct?
In principle. The file handle actually contains a 'dev', indicating the
filesystem, the inode number of the file, and a generation number used
to avoid confusion if the file is deleted and the inode reused for
another file. You could arrange things so that the secondary server has
the same FS dev... but there is no guarantee that equivalent files will
have the same inode number; (depends on order of file creation etc.)
And finally the kicker is that the generation number on any given system
will almost certainly be different on equivalent files, since it's
created from a random seed.
> If so is it possible to generate a filehandle only on the
> path/name of the file say?
>
> Thanks Joe
Well, as I explained, the file handle doesn't contain anything
explicitly related to the pathname. (File handles aren't big enough for
that; only 32 bytes in NFS2, up to 64 in NFS3.)
Trying to change the way file handles are generated would be a MASSIVE
redesign project in the NFS code, I'm afraid... In fact, you would
really need some kind of "universal invariant file ID" which would have
to be supported by the underlying local filesystem, so it would ramify
heavily into other parts of the system too...
NFS just doesn't lend itself to replication of 'live' filesystems in
this manner. It was never a design consideration when it was being
developed (over 15 years ago, now!)
There HAVE been a number of heroic (and doomed!) efforts to do this kind
of thing; for example, Auspex had a project called 'serverguard' a few
years ago into which they poured millions in resources... and never got
it working properly... :-(
Sorry. Not the answer you were hoping for, I guess...
Dave Higgen
|
