[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gluster-devel] write-behind bug with ftruncatz (was: Re: cache problem?

From: Emmanuel Dreyfus
Subject: [Gluster-devel] write-behind bug with ftruncatz (was: Re: cache problem?)
Date: Sat, 16 Jul 2011 14:19:56 +0200
User-agent: MacSOUP/2.7 (unregistered for 1638 days)

Emmanuel Dreyfus <address@hidden> 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

Above write-behind, we get this:
write(sizeA, offsetA)
write(sizeB, offsetB)
write(sizeC, offsetC)
write(sizeD, offsetD)

And below, this turns into:
write(sizeA, offsetA)
write(sizeB, offsetB)
write(sizeC, offsetC)
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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]