:Me too ;)
:
:I got almost 300 of these messages during a "make release" with the
:chroot dir NFS mounted. Otherwise I had no problems with such over
:NFS created files though.
:
:Daniel
I think I've tracked it down. When the client close()'s an NFS filehandle
it calls nfs_flush() without specifying that a commit should be done, then
clears the NMODIFIED bit in np->n_flags. It is not legal to clear
NMODIFIED if no commit is done.
Clearing NMODIFIED prematurely causes NFS to believe that there are no
dirty buffers to destroy when a new file is created with O_TRUNC or
ftruncate(). This will not lead to any problems if all you are doing is
appending, it will lead to problems if you seek/write around after
truncating the file.
I think the correct solution is simply to not clear NMODIFIED on the
last close.
Please try this patch to -current
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
Index: nfs_vnops.c
===================================================================
RCS file: /FreeBSD/FreeBSD-CVS/src/sys/nfs/nfs_vnops.c,v
retrieving revision 1.149
diff -u -r1.149 nfs_vnops.c
--- nfs_vnops.c 1999/12/15 23:02:19 1.149
+++ nfs_vnops.c 2000/01/04 18:26:50
@@ -561,10 +561,15 @@
if ((VFSTONFS(vp->v_mount)->nm_flag & NFSMNT_NQNFS) == 0 &&
(np->n_flag & NMODIFIED)) {
if (NFS_ISV3(vp)) {
+ /*
+ * Note: Since we haven't committed the buffers we cannot
+ * clear the NMODIFIED np->n_flag
+ */
error = nfs_flush(vp, ap->a_cred, MNT_WAIT, ap->a_p, 0);
- np->n_flag &= ~NMODIFIED;
- } else
+ /* np->n_flag &= ~NMODIFIED; */
+ } else {
error = nfs_vinvalbuf(vp, V_SAVE, ap->a_cred, ap->a_p, 1);
+ }
np->n_attrstamp = 0;
}
if (np->n_flag & NWRITEERR) {
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
