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:
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 in-memory representation of the timestamp. This seems to allow setting over 2038. The on-disk 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: https://lkml.org/lkml/2014/6/1/240
Hello Amar,Am Mo., 15. Apr. 2019 um 11:27 Uhr schrieb Amar Tumballi Suryanarayan <atumball@xxxxxxxxxx>:On Mon, Apr 15, 2019 at 2:40 PM David Spisla <spisla80@xxxxxxxxx> wrote:Hi folks,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:# stat /gluster/brick1/glusterbrick/data/file3.txt
File: /gluster/brick1/glusterbrick/data/file3.txt
Size: 5 Blocks: 16 IO Block: 4096 regular file
Device: 830h/2096d Inode: 115 Links: 2
Access: (0544/-r-xr--r--) Uid: ( 2000/ gluster) Gid: ( 2000/ gluster)
Access: 1934-12-13 20:45:51.000000000 +0000
Modify: 2019-04-10 09:50:09.000000000 +0000
Change: 2019-04-10 10:13:39.703623917 +0000
Birth: -From FUSE I get the correct atime:# stat /gluster/volume1/data/file3.txt
File: /gluster/volume1/data/file3.txt
Size: 5 Blocks: 1 IO Block: 131072 regular file
Device: 2eh/46d Inode: 10812026387234582248 Links: 1
Access: (0544/-r-xr--r--) Uid: ( 2000/ gluster) Gid: ( 2000/ gluster)
Access: 2071-01-19 03:14:07.000000000 +0000
Modify: 2019-04-10 09:50:09.000000000 +0000
Change: 2019-04-10 10:13:39.705341476 +0000
Birth: -From FUSE you get the time of what the clients set, as we now store timestamp as extended attribute, not the 'stat->st_atime'.This is called 'ctime' feature which we introduced in glusterfs-5.0, It helps us to support statx() variables.So I am assuming that the values in the default xfs timestamps are not important for WORM, if I use storage.ctime?Does it work correctly with other clients like samba-vfs-glusterfs?_______________________________________________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:1. Why it is possible to set atime on XFS greater than 2038?2. And why this atime switched to a time lower 1970 after a while?RegardsDavid Spisla
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-users--Amar Tumballi (amarts)
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx https://lists.gluster.org/mailman/listinfo/gluster-users
