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 observed, 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/
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/
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?

I did everything on a SLES15 machine. xfsprogs is version 4.15 and Gluster is v5.5

  • Interesting question. I would advise detailing the linux distribution and versions of software though. Dont forget to put John Titor on the loop. ;) – Rui F Ribeiro Apr 15 at 11:45
  • I add the versions and distribution info – davids Apr 15 at 13:16
  • @RuiFRibeiro Who ist John Titor and what does the loop mean? Excuse me the question, but I am completely new here – davids Apr 15 at 13:17
  • "Titor claimed to be an American soldier from 2036, based in Tampa, Florida. He was assigned to a governmental time-travel project, and sent back to 1975 to retrieve an IBM 5100 computer which he said was needed to debug various legacy computer programs in 2036" for dealing with the UNIX year 2038 bug. – Rui F Ribeiro Apr 15 at 13:20
  • Hahaha Allrigth, I understand ;-) – davids Apr 15 at 13:31

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.