XFS、GlusterFS v5.5、および2038年発行

XFS、GlusterFS v5.5、および2038年発行

たとえば、保存日を2071に設定するなど、デフォルトの保存期間を試しました。 WORMingをすると、すべてが大丈夫そうです。 FUSEとブリックレベルでは、予約はすべてのノードで2071に設定されます。また、storage.ctimeタイムスタンプ mdata xattrも保存するオプションを有効にしました。しかし、しばらくすると、ブリックレベル atime(ストレージの保存)が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: -

FUSEで正しい時間を取得します。\

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

私はXFSが32ビットタイムスタンプ値のみをサポートしていることを発見しました。したがって、atime2071に設定することは私の予想では不可能です。ところが最初は2071年でしたが、後にYEAR-2038の問題により1934年に変わりました。私は自分にこう尋ねました。
atime1. XFSを2038より大きく設定できるのはなぜですか?
2.atime時間が経つと、なぜ1970年以下の時間に変わりますか?

私はSLES15マシンですべてのことをしました。 xfsprogs はバージョン 4.15、Gluster は v5.5 です。

ベストアンサー1

LastAccess日付がブロックレベルで変更される理由と、XFSがINT32フィールドに2070などの日付を保存できる理由の考えられる説明:

驚くべきことに、atimeのタイムスタンプを2038よりはるかに高く設定でき、これらのタイムスタンプは一般的なシステムツールでも表示できます。時間が経つと、値が変わり、1902-1969年の範囲にマッピングされることが観察されます。最初は、2038年の固定時間よりもはるかに多くの時間を正常に設定したと考えられます。記憶の中タイムスタンプ表現。これは2038以降の設定を許可しているようです。ディスク上一方、XFS表現は最大値2038のみを受け入れ、上記の値はsigned int32の負の範囲である1902-1969の範囲にマッピングされます。私がそのスレッドから持ってきたものは次のとおりです。 https://lkml.org/lkml/2014/6/1/240

おすすめ記事