Re: Consistent time attributes (ctime, atime and mtime) across replica set and distribution set

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Thu, Mar 16, 2017 at 6:52 AM, Soumya Koduri <skoduri@xxxxxxxxxx> wrote:


On 03/16/2017 02:27 PM, Mohammed Rafi K C wrote:


On 03/15/2017 11:31 PM, Soumya Koduri wrote:
Hi Rafi,

I haven't thoroughly gone through design. But have few
comments/queries which I have posted inline for now .

On 02/28/2017 01:11 PM, Mohammed Rafi K C wrote:
Thanks for the reply , Comments are inline



On 02/28/2017 12:50 PM, Niels de Vos wrote:
On Tue, Feb 28, 2017 at 11:21:55AM +0530, Mohammed Rafi K C wrote:
Hi All,


We discussed the problem $subject in the mail thread [1]. Based on the
comments and suggestions I will summarize the design (Made as
points for
simplicity.)


1) As part of each fop, top layer will generate a time stamp and
pass it
to the down along with other param.

    1.1) This will bring a dependency for NTP synced clients along
with
servers
What do you mean with "top layer"? Is this on the Gluster client, or
does the time get inserted on the bricks?
It is the top layer (master xlator) in client graph like fuse, gfapi,
nfs . My mistake I should have mentioned . Sorry for that.

These clients shouldn't include internal client processes like
rebalance, self-heal daemons right? IIUC from [1], we should avoid
changing times during rebalance and self-heals.

Also what about fops generated from the underlying layers -
getxattr/setxattr which may modify these time attributes?

Since the time stamps are appended from master xlators like fuse , we
will not have the timestamp for internal daemons as they don't have
master xlator loaded. internal fops won't generate new timestamp , even
if we are sending an internal fops from say dht, it will have only one
time genrated by fuse. So I think this is fine.

Okay. But since self-heal and snapview-server (atleast) seem to be using gfapi, how can gfapi differentiate between these internal clients and other applications (like NFS/SMB)? I thought we need intelligence on server-side to identify such clients based on pid and then avoid updating timestamp sent by them.


Very good point. Considering we should be using gfapi in future for most of the internal processes, this becomes more important. Should we just add it as argument to glfs_init() options? If you set a flag during init, the ctime xattr is not generated for the fops which otherwise generate and send them.

-Amar

 

Thanks,
Soumya
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel



--
Amar Tumballi (amarts)
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux