<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 15, 2019 at 2:40 PM David Spisla <<a href="mailto:spisla80@gmail.com">spisla80@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi folks,</div><div>I tried out default retention periods e.g. to set the Retention date to 2071. When I did the WORMing, everything seems to be OK. From FUSE and also at Brick-Level, the retention was set to 2071 on all nodes.Additionally I enabled the storage.ctime option, so that the timestamps are stored in the mdata xattr, too. But after a while I obeserved, that on Brick-Level the atime (which stores the retention) was switched to 1934:</div><div><br></div><div># stat /gluster/brick1/glusterbrick/data/file3.txt <br> File: /gluster/brick1/glusterbrick/data/file3.txt<br> Size: 5 Blocks: 16 IO Block: 4096 regular file<br>Device: 830h/2096d Inode: 115 Links: 2<br>Access: (0544/-r-xr--r--) Uid: ( 2000/ gluster) Gid: ( 2000/ gluster)<br>Access: 1934-12-13 20:45:51.000000000 +0000<br>Modify: 2019-04-10 09:50:09.000000000 +0000<br>Change: 2019-04-10 10:13:39.703623917 +0000<br> Birth: -<br></div><div><br></div><div>From FUSE I get the correct atime:</div><div># stat /gluster/volume1/data/file3.txt <br> File: /gluster/volume1/data/file3.txt<br> Size: 5 Blocks: 1 IO Block: 131072 regular file<br>Device: 2eh/46d Inode: 10812026387234582248 Links: 1<br>Access: (0544/-r-xr--r--) Uid: ( 2000/ gluster) Gid: ( 2000/ gluster)<br>Access: 2071-01-19 03:14:07.000000000 +0000<br>Modify: 2019-04-10 09:50:09.000000000 +0000<br>Change: 2019-04-10 10:13:39.705341476 +0000<br> Birth: -<br></div><div><br></div></div></div></div></div></div></div></blockquote><div><br></div><div>From FUSE you get the time of what the clients set, as we now store timestamp as extended attribute, not the 'stat->st_atime'.</div><div><br></div><div>This is called 'ctime' feature which we introduced in glusterfs-5.0, It helps us to support statx() variables.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div></div><div>I find out that XFS supports only 32-Bit timestamp values. So in my expectation it should not be possible to set the atime to 2071. But at first it was 2071 and later it was switched to 1934 due to the YEAR-2038 problem. I am asking myself:</div><div>1. Why it is possible to set atime on XFS greater than 2038?</div><div>2. And why this atime switched to a time lower 1970 after a while?</div><div><br></div><div>Regards</div><div>David Spisla<br></div><div><br></div></div></div></div></div></div></div>
_______________________________________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
<a href="https://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-users</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Amar Tumballi (amarts)<br></div></div></div></div></div></div>