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

Amar Tumballi Suryanarayan atumball at redhat.com
Mon Apr 15 09:26:46 UTC 2019


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


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


More information about the Gluster-users mailing list