On 12/18/2014 03:37 PM, Sage Weil wrote: > On Thu, 18 Dec 2014, Wido den Hollander wrote: >> Hi, >> >> I've been playing around a bit with the recursive statistics for CephFS >> today and I'm seeing some behavior with the rstats what I don't understand. >> >> I /A/B/C in my CephFS. >> >> I changed a file in 'C' and the ceph.dir.rctime xattr changed >> immediately. I've been waiting for 60 minutes now, but /A and /A/B still >> have their old rctime. >> >> A: 1418905422 (18-12-2014 13:23:42) >> B: 1418905422 (18-12-2014 13:23:42) >> C: 1418909134 (18-12-2014 14:25:34) >> >> It's 15:21:34 right now, so after 1 hour the rctime of A and B still >> hasn't updated. >> >> How long does this take? I know the MDS is lazy in updating the rstats, >> but one hour is quite long, isn't it? > > This is a bit of a loose end at the moment. The client doesn't have any > refresh value for these stats. Right now an 'ls' in the parent dir will > get you a fresh value, but repeatedly calling 'stat' will keep giving you > the cached value. > The ls didn't really trigger it for me. I'm using getfattr btw: $ getfattr -n ceph.dir.rctime /mnt/cephfs/A I unmounted and mounted and it worked right away. So this is probably not a real issue on a active filesystem where lots of I/O on that client is happening, right? I'm building a PoC backup script which uses the rctimes to backup CephFS in a reasonable way, not having rsync scan the whole tree. > I'm not sure what the right fix is. The normal inode fields are all > perfectly accurate, and the protocol is built around making sure that's > the case.. not giving "reasonably timely" values to the new stuff. :/ > > sage > -- Wido den Hollander 42on B.V. Ceph trainer and consultant Phone: +31 (0)20 700 9902 Skype: contact42on _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |