On Thu, 2011-09-29 at 15:05 -0400, Dave Jones wrote: > On Thu, Sep 29, 2011 at 02:59:32PM -0400, Trond Myklebust wrote: > > > 1) What filesystem are you using on the server, and does that filesystem > > support high resolution timestamps? > > ext3 Hmm... Is the problem also reproducible with ext4 or xfs? ext3 has the issue that mtime/ctime timestamps are only accurate to within 1 second, and so the client often has trouble figuring out which returned attribute values reflect the most recent state on the server when several RPC calls have been transmitted in parallel. > > 2) Does the file length on the server match the reported erroneous file > > length on the client? > > No. Server side is 213853 bytes (0x3435d) Ouch. That would seem to indicate that something is happening after the truncate(). I would have expected the server to show 0x3210a... > > 3) Do the mtime and ctime on the erroneous file match on the client and > > server? > > both show.. > Modify: 2011-09-29 13:50:00.000000000 -0400 OK. This result looks consistent with the hypothesis put forward under question (1) above. However your reply to (2) does not. Let me investigate and see if I can reproduce it... -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
