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.
> 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
