<div dir="ltr"><div>Hello Gluster Community,</div><div>
<div class="gmail-post-text">
<p>here is a possible explanation why the LastAccess date is changed at brick level resp
why can XFS ever have a date of e.g. Can store 2070 in an INT32 field:</p>
<p>It's amazing that you can set timestamps well above 2038 for the
atime and these are also displayed via the usual system tools. After a
while, it was observed that the values change and are mapped to the
range between 1902-1969. I suspect that the initially successful setting
of a well over 2038 stationary atime corresponds to an <strong>in-memory</strong> representation of the timestamp. This seems to allow setting over 2038. The <strong>on-disk</strong>
representation of XFS, on the other hand, only allows the maximum value
of 2038, values above are then mapped to the range 1902-1969, which
is the negative number range of a signed int32. This is what I have
taken from this thread:
<a href="https://lkml.org/lkml/2014/6/1/240" rel="nofollow noreferrer">https://lkml.org/lkml/2014/6/1/240</a></p>
</div>Finally I observed, that after reboot or remount of the XFS Filesystem the in-memory representation changes to the on-disk representation. Concerning the WORM functionality it seems to be neccessary to enable the ctime feature, otherwise the information of the Retention would be lost, if the Retention date is above 2038 in case of reboot or remount of the XFS Filesystem.<br></div><div><br></div><div>Regards</div><div>David Spisla<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mo., 15. Apr. 2019 um 11:51 Uhr schrieb David Spisla <<a href="mailto:spisla80@gmail.com">spisla80@gmail.com</a>>:<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>Hello Amar,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mo., 15. Apr. 2019 um 11:27 Uhr schrieb Amar Tumballi Suryanarayan <<a href="mailto:atumball@redhat.com" target="_blank">atumball@redhat.com</a>>:<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"><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" target="_blank">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></div></blockquote><div> So I am assuming that the values in the default xfs timestamps are not important for WORM, if I use storage.ctime?</div><div>Does it work correctly with other clients like samba-vfs-glusterfs?<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 class="gmail_quote"><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-m_6197204140197225057gmail-m_23050099220210740gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Amar Tumballi (amarts)<br></div></div></div></div></div></div>
</blockquote></div></div>
</blockquote></div>