Anand Avati <anand.avati@xxxxxxxxx> 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 manu@xxxxxxxxxx
