Emmanuel Dreyfus <manu@xxxxxxxxxx> wrote: > client# md5 gnusrc.tgz > MD5 (gnusrc.tgz) = 471a73c374ec2b5733571c01647a69d5 > > server# md5 /export/wd3a/tmp/gnusrc.tgz > MD5 (/export/wd3a/tmp/gnusrc.tgz) = cf03446a7f31713002ef3b74020b173f Here are the results of my investigations. It seems this is caused on the client, by reordering of ftruncate() and write() by performance/write-behind Above write-behind, we get this: write(sizeA, offsetA) ftruncate(offsetB) write(sizeB, offsetB) write(sizeC, offsetC) write(sizeD, offsetD) And below, this turns into: write(sizeA, offsetA) write(sizeB, offsetB) write(sizeC, offsetC) ftruncate(offsetB) write(sizeD, offsetD) Result is that data between offsetB and offsetD is filled with zeros. Removing the performance/write-behind xlator on the client fixes the problem. Nobody else got this problem? It may be NetBSD-specific, since the ftruncate() come from FUSE SETATTR issued by the NetBSD kernel to update the file size. I could filter out such messages, but I am not sure it would not have side effects. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu@xxxxxxxxxx
