Ceph » CephFS

I think you're right -- well spotted! In particular, we need to bump it in the case where we update the ctime (ceph.file.layout only so far).

That said, now that I look. Should we be updating the ctime and change_attr in the ceph.dir.layout case as well? And why not for ceph.quota ? It is a metadata change so it seems like we should do it for all of them.

Thoughts?

Should we be updating the ctime and change_attr in the ceph.dir.layout case as well?

Did you mean mtime?

I think updating mtime and change_attr for vxattr changes makes sense.

No, I mean the ctime. You only want to update the mtime if you're changing the directory's contents. I would consider the layout to be a a metadata change, so I think you just want to update the ctime and the change_attr.

Intuitively I would say that things we expose as xattrs should probably bump ctime when they're set, if we're being consistent about pretending that they're posix-ish file metadata.

I guess the counter argument would be that if we're dealing with an rsync-like tool which will in practice ignore the ceph.* attrs, then it's annoying if we bump ctime if there isn't really anything they need to update.

Given how rare our changes the user-modifiable ceph.* attrs are though, that rsync case is probably not painful in practice, probably?

John Spray wrote:

Intuitively I would say that things we expose as xattrs should probably bump ctime when they're set, if we're being consistent about pretending that they're posix-ish file metadata.

Yes. That sort of thing is rather nice when you consider stuff like intrusion detection, which likes to be able to tell when someone has monkeyed with the file.

I guess the counter argument would be that if we're dealing with an rsync-like tool which will in practice ignore the ceph.* attrs, then it's annoying if we bump ctime if there isn't really anything they need to update.

Given how rare our changes the user-modifiable ceph.* attrs are though, that rsync case is probably not painful in practice, probably?

Yeah, seems like a minor concern.

In any case, I'm not sure rsync would actually do anything there once it looked at the file and tried to calculate the delta. In practice you can't set ctime to a particular value using normal POSIX APIs. The act of changing the ctime is itself a ctime change, and so you just end up with it always marching into the future for any given inode.