Re: [Gluster-devel] write-behind bug with ftruncate

[Emmanuel Dreyfus]

Anand Avati <address@hidden> wrote:

> I still do not see a problem here. Gluster is not relying on any
> undocumented behavior. If a SETATTR call is sent with both atime/mtime and
> size, Gluster replies only after performing actions for all of those bits.

Sorry, the logs I sent were incomplete, it lacked the relevant bit. I
got really confused on this one, but now I understand better. Here is a
relevant log:

fuse_write()    size = 4096, offset = 39981056
fuse_setattr()  fsi->valid = 0x78 => truncate_needed,  size = 39987632
fuse_write()    size = 20480, offset = 39985152
(...)
client3_1_writev()      size = 4096, offset = 39981056
(...)
fuse_write()     size = 12 288, offset = 40947712
(...)
fuse_setattr_cbk()      call fuse_do_truncate, offset = 39987632
client3_1_writev()      size = 2480, offset = 39985152
(...)
client3_1_writev ()     size = 12288, offset = 40947712
client3_1_ftruncate()   offset = 39987632

The write at offset = 40947712 was erased by an out of order ftruncate.

As I understand, when glusterfs gets setattr atime/mtime/size, it does
postpone the size change, and this cause a race with write.

> Whether it performs the actions in two separate internal calls or one is of
> no concern to FUSE. Can you please describe what was the change you
> performed in your FUSE implementation?

I look for size change without uid, gid, and mode, and on match I remove
atime and mtime:
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libperfuse/ops.c.diff?r1=1.3
3&r2=1.34

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
address@hidden