> >>>>> " " == Jeff Epler <jepler@inetnebr.com> writes:
>
> > Is there a solution that would allow the kind of guarantee our
> > software wants with non-linux nfsds without the cache-blowing
> > that the change I'm suggesting causes?
>
> How about something like the following compromise?
>
> I haven't tried it out yet (and I've no idea whether or not Linus
> would accept this) but it compiles, and it should definitely be better
> behaved with respect to slowly-changing files.
>
> As you can see, the idea is to look at whether or not the file has
> changed recently (I arbitrarily chose a full minute as a concession
> towards clusters with lousy clock synchronization). If it has, then
> the page cache is zapped. If not, we force ordinary attribute cache
> consistency checking.
The fix still does not provide coherency guarantees in all situations, and
at minimum, there ought to be a way to force the client provide a coherency
guarantee.
> Cheers,
> Trond
>
> --- linux-2.4.0-test8/fs/nfs/file.c Fri Jun 30 01:02:40 2000
> +++ linux-2.4.0-test8-fix_lock/fs/nfs/file.c Thu Sep 14 09:18:50 2000
> @@ -240,6 +240,20 @@
> }
>
> /*
> + * Ensure more conservative data cache consistency than NFS_CACHEINV()
> + * for files that change frequently. Avoids problems with sub-second
> + * changes that don't register on i_mtime.
> + */
> +static inline void
> +nfs_lock_cacheinv(struct inode *inode)
> +{
> + if ((long)CURRENT_TIME - (long)(inode->i_mtime + 60) < 0)
> + nfs_zap_caches(inode);
> + else
> + NFS_CACHEINV(inode);
> +}
> +
> +/*
> * Lock a (portion of) a file
> */
> int
> @@ -295,6 +309,6 @@
> * This makes locking act as a cache coherency point.
> */
> out_ok:
> - NFS_CACHEINV(inode);
> + nfs_lock_cacheinv(inode);
> return status;
> }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:24 EST