Re: ctime weirdness

[Anand Avati <avati@xxxxxxxxxxx>]

I don't think the problem is with the handling of SETATTR in either NetBSD or Linux. I am guessing NetBSD FUSE is _using_ SETATTR to update atime upon open? Linux FUSE just leaves it to the backend filesystem to update atime. Whenever there is a SETATTR fop, ctime is _always_ bumped.

Thanks

On Mon Jan 12 2015 at 5:03:51 PM Emmanuel Dreyfus <manu@xxxxxxxxxx> wrote:

Hello

Here is a NetBSD behavior that looks pathological:
(it happens on a FUSE mount but not a native mount):

# touch a
# stat -x a
  File: "a"
  Size: 0            FileType: Regular File
  Mode: (0644/-rw-r--r--)         Uid: (    0/    root)  Gid: (    0/
wheel)
Device: 203,7   Inode: 13726586830943880794    Links: 1
Access: Tue Jan 13 01:57:25 2015
Modify: Tue Jan 13 01:57:25 2015
Change: Tue Jan 13 01:57:25 2015
# cat a > /dev/null
# stat -x a
  File: "a"
  Size: 0            FileType: Regular File
  Mode: (0644/-rw-r--r--)         Uid: (    0/    root)  Gid: (    0/
wheel)
Device: 203,7   Inode: 13726586830943880794    Links: 1
Access: Tue Jan 13 01:57:31 2015
Modify: Tue Jan 13 01:57:25 2015
Change: Tue Jan 13 01:57:31 2015

NetBSD FUSE implementation does not sends ctime with SETATTR. Looking at
glusterfs FUSE xlator, I see setattr code does not handle ctime either.

How does that happen? What wrong does NetBSD SETATTR does?

--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@xxxxxxxxxx
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel

_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel