lkml.org 
[lkml]   [1996]   [Dec]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: NFS Problem in Kernel 2.0.27: inode status not updated
Date
> >There is nothing in the NFS spec that requires the client to update its
> >cached link count[*].
> I think you're wrong here. NFS, if used from a UNIX host is supposed to

He's right. NFS cannot support Unix (POSIX) file semantics. NFSv2 is a
totally broken protocol. NFS can delete files at random if packets get
re-ordered and many other horrible things.

> If, after a link() call, the attribute would still display only one hardlink
> due to caching, then your caching mechanism clearly is broken.

NFS doesn't guarantee that you have a link count that works like unix. Several
non UNIX NFS servers always report 1 link. Using that approach in your
application is broken.

> *if* the hardlink returned success. If the hardlink returns failure,
> the attribute cache *must* be flushed (a consistent view of the
> filesystem cannot be guaranteed otherwise).

NFS doesn't guarantee a consistent view of the file system anyway. Read
the spec.

> The actual NFS specs aren't even that important at this point. Simply
> the fact that you're trying to present UNIX filesystem semantics already
> dictates when the cache needs to be updated or flushed.

NFS does not support Unix file system semantics. Full stop, end of story.
Even altering the cached attributes will not save you as your cache
may be invalid anyway. Indeed NFS allows an unlink to be delayed
occur out of order and delete megabytes of valuable newly created data.

Alan


\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.738 / U:1.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site