l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2005 Mar 17 23:24

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
[vox-tech] resolved (kind of): stale NFS file (was: binaryequivalence of two directories)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Thu 17 Mar 05,  6:49 PM, Mitch Patenaude <patenaude@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:


> 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.



> 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

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.

vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.