Does anyone know any nfs client public domain on PC/DOS?

NFS always returns NFSERR_STALE if it cannot convert a file handle into
a valid v-node pointer (see fhtovp()/nfs_server.c). This makes a binary
search impossible.

        Leendert

NFS servers that don't implement per-filesystem export properties such as
these can get away with leaving the export file id out of the file handle.
But SunOS can't.
--
Barry Margolin, Thinking Machines Corp.

It would perhaps be possible to check the exports list at every NFS operation,
but it would be expensive, and I doubt whether anyone has implemented it.

It's not that expensive. You just walk through a linked list which isn't
all that long. That's what Sun's NFS server does on every NFS operation.

However, if you are hitting the data that well then it is probable that
you are also hitting the inode cache as well.  The inode cache is what
is queried for the getattrs/lookups.

        Push the inode to disk so that it reflects the new size, if changed.
        Push the indirect block of pointers to disk after allocating.
        Push the data to disk.

The first write happens when you are sequentially writing a new file.
Rewrites probably don't bother (they should to save the modtime, but
I'll bet that is "optimized" out).

The second write starts happen for each block past the direct blocks.
The first 9 (12? I can never remember) block pointers are stored in the
inode, the next pointer points to a block of pointers, and so on.  As
the file gets large, you're allocating out of that block of pointers;
that allocation needs to get saved to disk.

The third write is obvious (I hope).

Sun can't afford to cheat.  Not like that.  Sun has many weak points,
many places where they fall short of customer expectations.  But data
written to disk is treated very carefully.

To defend Vern somewhat, why should data written by an NFS client be
treated differently than data written by an NFS server?  If I run a make
on an NFS client and the server crashes, why should that be any different
than running the same make on the server and having it crash?  That is,
if a Unix server crashes, I expect to lose the last 30 seconds or so of
work, and I probably will (depending on timing), if I work on the server.
Why shouldn't I expect the same data loss if I work on a client instead?

 1. As I keep writing, it's an option.  If you care, don't turn it on.

 2. If Citibank really does use NFS for their money, than I'm glad
    I don't have a Citibank bank card!  NFS has nothing to do with a
    genuine transaction database.

 3. I don't think it's a "pat on the back."  As we've hashed out until
    we're all sick of it, there is no rational difference between a Legato
    board in a Sun and some other brand of computer with a UPS.  that only
    part of the memory in one of those two has a battery is irrelevant for
    "data integrety" concerns.  It does materially affect the profits of
    the company selling the expensive boards.

 4. My personal experience with SGI and Sun machines in the last few years
    is that both are more likely to loose data after it is already properly
    on the disk than due to a crash before a sync.  UNIX kernels are and
    should be as robust as disk drives.
    Disclaimer:  My recent experience with Sun's is less than with IRIS's.

 5. It would be great if Sun would get off it's fundament and get out a
    protocol turn with fixes the several bad bugs in the NFS protocol.
    Sun's bureaucratic paralysis is destroying NFS.  There are some modest
    things that could be done to NFS to make it competative with AFS.
    Because Sun is so dead, NFS is itself moribund.

    The absense of an fsync operation over the wire is a bug, although not
    as important as others, such as the absense of atomic-create, which has
    caused Sun and others so much trouble with a certain locking morass,

 6. It is very hard for anyone but Sun to extend or fix a Sun protocol!
    Maybe almost as hard as for Sun itself.
    Yes, I know about RPC numbers.  For example, you may have noticed that
    Silicon Graphics has registered NIS to get it an IP multicast address.
    I've been nagging Sun about that for years.  No, Silicon Graphics makes
    no claim about the ownership of that Class D address.  We just want to
    get away from the silliness of one NIS server/wire and got tired of
    waiting.