[vox-tech] resolved (kind of): stale NFS file (was: binary equivalence of two directories)

[Peter Jay Salzman]

On Thu 17 Mar 05,  6:49 PM, Mitch Patenaude <patenaude at gmail.com> said:
> Hmm... just a guess.  Is lockd running on lucifer?
> 
> File locking was added in NFS4, but for backward compatibility it was
> run in a separate daemon.  I'm guessing that most programs don't
> bother with file locking, but it wouldn't surprise me if diff did.  If
> lockd weren't running, then it would be unable to lock the file, which
> it might interpret as a stale file handle.
> 
> This is all supposition, and I may have some of the details wrong,
> since I haven't mucked with NFS in years.
> 
>   -- Mitch

It appears that I have stumbled onto a bug that exists (and apparently, has
always existed).  NFS mounting a vfat or msdos partition has issues.  Here's
a conversation I had with an NFS developer:



==========================================================================
(snip)

> My computer lucifer is a dual boot machine.  While booted in Linux, it
> uses NFS to export /C, /D and /E (Windows partitions) to other computers
> on my LAN.

What kind of Windows partitions?  The problem you are seeing looks like the
generic problem of exporting vfat/msdos partitions over NFS.

Basic filehandle generation is broken on vfat/msdos, because the default
export operations that knfsd tries to use rely on the inode numbers being
permanent (something which is not the case here). It may perhaps be possible
to write a set of custom export_opertions for them, but nobody has yet
stepped up to the plate to do so.

Cheers,
  Trond

==========================================================================
(snip)

> In layman's terms, the problem is that the inodes used to describe where
> files reside on a vfat-mounted partition can change.  In other words,
> inode X belonging to some file residing on vfat can change into inode
> X+Y.  Even if there's no actual disk writing involved (like my diff
> example).

The inode _number_, which is basically a way of referencing the file
that is meant to be independent of the filename. This is useful if your
filesystem has the concept of "hard links" (as most UNIX filesystems
do), and/or if you want to be able to reference the same file after
renames.

The command 'ls -i' will list the inode number associated to a file.

> Couldn't that eventually lead to filesystem corruption?

The vfat/msdos filesystem itself will not rely on inode numbers in order
to locate the file, so you will be safe in the case of local use.

The problem is that the NFS server, by default *does* rely on the inode
number for tracking the file. Yes, that may lead to corruption, but more
frequently, it will just lead to the NFS server losing track of your
file (and returning random ESTALE errors).

As I said, there is a programming interface to allow knfsd to use
alternate means for tracking the file, if one exists, but nobody has
worked on setting up such a system for vfat/msdos.

Cheers,
  Trond