I thought at first it was my imagination, but after a couple of incidents
I'm convinced that I'm seeing file corruption under 2.1.88 and 89. All
three incidents have involved data being written from a 2.1.8[8-9] client
to a server machine running same.
In at least the last two of them, the target file is the correct length,
but shows massive corruption starting on a nice, even 16-byte boundary. I
know there's been some playing around with the VM system lately; could
this be causing it?
There are absolutely no ugly messages in the server's log files.
Client-side, there were these (timestamped about 25-minutes _prior_ to the
most recent event):
Mar 9 18:09:04 air kernel: nfs_refresh_inode: mismatch, ino=257, fattr=0
Mar 9 18:09:04 air kernel: nfs_refresh_inode: mismatch, ino=258, fattr=0
Mar 9 18:09:04 air kernel: nfs_refresh_inode: mismatch, ino=259, fattr=0
I suppose gremlins could be springing from the network layer, but I export
an X display across the same ethernet from server to client and nothing's
amiss with it.
Are there any particular debugging flags you would like switched on?
Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu