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>
Amar Tumballi Suryanarayan
2019-Apr-15 09:26 UTC
[Gluster-users] XFS, WORM and the Year-2038 Problem
On Mon, Apr 15, 2019 at 2:40 PM David Spisla <spisla80 at gmail.com> 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 storetimestamp 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.> 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 > > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > https://lists.gluster.org/mailman/listinfo/gluster-users-- Amar Tumballi (amarts) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20190415/cbb13271/attachment.html>