On 03/08/2017 01:05 AM, Amar Tumballi wrote:
son, for ex: because of locks.
2) On the server posix layer stores the value in the memory (inode ctx)
and will sync the data periodically to the disk as an extended attr
I believe this should not be a part of the posix xlator. our posix store
definition is that it uses a local file-system underneath that is POSIX
compliant. This need, for storing the time information outside of POSIX
specification (as an xattr or otherwise), is something that is gluster
specific. As a result we should not fold this into the posix xlator.
For example, if we replace posix later with a db store, or a key-vlaue
store, we would need to code this cache management of time information
again for these stores, but if we abstract it out, then we do not need
to do the same.
I see this xattr similar to that of 'gfid'. Because as gfid is like our
'stat->st_ino', this xattr will be our 'stat->st_{c,m,a}time', which is
very much a part of backend support requirement IMO.
Yes, that part I agree.
I am more talking about delayed sync of these attrs as a (possibly)
separate layer, so that it can be utilized across other backends, if and
when that happens.
I may need to chew on this further, but at the moment I think this
functionality should be stuffed into posix-xlator, and rather should
live on its own.
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel
