On Thu 17 Mar 05, 6:49 PM, Mitch Patenaude <[EMAIL PROTECTED]> 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 _______________________________________________ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
