[Gluster-users] XFS, WORM and the Year-2038 Problem

[David Spisla]

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

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?

Regards
David Spisla
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20190415/b866621e/attachment.html>