☰

XFS, GlusterFS v5.5 및 2038년 발행물

tag-icon • tag-icon linux sles xfs glusterfs
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

관련 정보