inode-errors bei nfs-server abfragen
Wollt nur mal saachen, mein syslog meldet bei Listingabfragen relativ oft:
Apr 10 09:29:37 localhost kernel: nfs_update_inode: inode number mismatch
Apr 10 09:29:37 localhost kernel: expected (0:12/0x3cc6193d), got (0:12/0x104b007b)
Der Fehler scheint aber keine weiteren Probleme zu verursachen. Mir sind zumindest keine aufgefallen. Eine kleine googelei ließmich üolgende Aussage stolpern:
++snipp1
Now I think I can see where the problem originates from: nfs-server
does vfs_getattr() from encode_fattr3(), but it doesn't check the
return value. So if getattr() fails, the attributes (including the
inode numebr) will be bogus.
I'll ask the NFS maintainer about this.
++snapp
++snipp2
I think there may be a second, similar bug. Over NFS, a typical
sequence on the client is:
OPEN
WRITE
CLOSE
On the server, this looks like:
OPEN
WRITE
FSYNC
RELEASE
The kernel nfsd doesn't use FLUSH, and the FSYNC is used to make the
write stable. However, there seems to be a bug in the nfsd where if
the WRITE succeeds, but the FSYNC fails, the client is incorrectly
told the stable write succeeded. For example, see the call to fsync()
in nfsd_dosync() which is called via nfsd_sync() in nfsd_write(). The
return code of fsync() isn't checked.
++snapp
Weis nicht ob das Problem wirklich wichtig ist oder ob die Problemlögsansäe helfen. Die Geschichten sind nicht meine Baustelle. :D
Ich wollte es nur mal mitteilen..
Die fehlermeldungen sehe ich sowohl unter darwin 10.5.2 als auch unter debian sarge aktuell
Apr 10 09:29:37 localhost kernel: nfs_update_inode: inode number mismatch
Apr 10 09:29:37 localhost kernel: expected (0:12/0x3cc6193d), got (0:12/0x104b007b)
Der Fehler scheint aber keine weiteren Probleme zu verursachen. Mir sind zumindest keine aufgefallen. Eine kleine googelei ließmich üolgende Aussage stolpern:
++snipp1
Now I think I can see where the problem originates from: nfs-server
does vfs_getattr() from encode_fattr3(), but it doesn't check the
return value. So if getattr() fails, the attributes (including the
inode numebr) will be bogus.
I'll ask the NFS maintainer about this.
++snapp
++snipp2
I think there may be a second, similar bug. Over NFS, a typical
sequence on the client is:
OPEN
WRITE
CLOSE
On the server, this looks like:
OPEN
WRITE
FSYNC
RELEASE
The kernel nfsd doesn't use FLUSH, and the FSYNC is used to make the
write stable. However, there seems to be a bug in the nfsd where if
the WRITE succeeds, but the FSYNC fails, the client is incorrectly
told the stable write succeeded. For example, see the call to fsync()
in nfsd_dosync() which is called via nfsd_sync() in nfsd_write(). The
return code of fsync() isn't checked.
++snapp
Weis nicht ob das Problem wirklich wichtig ist oder ob die Problemlögsansäe helfen. Die Geschichten sind nicht meine Baustelle. :D
Ich wollte es nur mal mitteilen..
Die fehlermeldungen sehe ich sowohl unter darwin 10.5.2 als auch unter debian sarge aktuell
1 person has this problem
I have this problem, too!
Tell me when someone solves it.
The more people who report this problem, the more it gets noticed.
The more people who report this problem, the more it gets noticed.
Loading Profile...


