lkml.org 
[lkml]   [1996]   [Dec]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: NFS Problem in Kernel 2.0.27: inode status not updated
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> >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.

I'm not saying that NFSv2 is *not* totally broken, but...
The case we're trying to support here is when there is *exactly* one
NFS server (running UNIX) and *exactly* one client (running UNIX).

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

What the application does if the filesystem does not support hardlinks,
is another matter (in my case, the application tries to take some
other adequate but far from perfect measures) and completely beside the
point. We're only discussing the problem where the NFS server is in fact
running UNIX.

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

If there is only one UNIX NFS-server, and there is only one UNIX NFS-client,
then the client OS *must* be able to get link() and stat() right in *all*
cases except for case when the NFS server should crash between having performed
a successful link() and reporting back success to the client.
The stat() call should return accurate data in *all* cases. The current
caching implementation in Linux does not guarantee this.

What will happen if there are more clients, is an entirely different
matter and currently not relevant (until the most simple case with
only one client works as described above).

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

I'm not saying that it has to support everything directly. But the
OS (Linux in this case) *must* emulate everything to the best of its
abilities (at least for the most simple case where it is the only
client; if it even takes care of the multiple client case, excellent,
but that's not the point here). Forgetting to increase the link count or
not flushing the cache is a blatant error.

>Even altering the cached attributes will not save you as your cache
>may be invalid anyway.

Not if you're the only client. I would expect *every* UNIX implementation
to get at least *that* right.

> Indeed NFS allows an unlink to be delayed
>occur out of order and delete megabytes of valuable newly created data.

Again, this is true (mostly in a multi-client scenario), but completely
beside the point.
--
Sincerely, srb@cuci.nl
Stephen R. van den Berg (AKA BuGless).

This sentance contains threee errors.

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