たとえば、保存日を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ビットタイムスタンプ値のみをサポートしていることを発見しました。したがって、atime
2071に設定することは私の予想では不可能です。ところが最初は2071年でしたが、後にYEAR-2038の問題により1934年に変わりました。私は自分にこう尋ねました。
atime
1. 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