Messages in this thread | | | From | Michael Eisler <> | Date | Thu, 14 Sep 2000 09:48:50 -0700 (PDT) | Subject | Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee |
| |
> >>>>> " " == 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/
| |