Bug #23380
mds: ceph.dir.rctime follows dir ctime not inode ctime
0%
Description
The original intention of the rctime was reflect the latest inode ctime in the children: https://lkml.org/lkml/2008/7/15/385
As of v12.2.4 this does not seem to be the case .. it is following the latest dir ctime of the children:
Initial empty dir: # getfattr -d -m ceph . | egrep 'bytes|ctime' ceph.dir.rbytes="0" ceph.dir.rctime="1521043742.09466372697" Create a file, rctime is updated: # touch a # getfattr -d -m ceph . | egrep 'bytes|ctime' ceph.dir.rbytes="0" ceph.dir.rctime="1521043831.0921836283" Modify a file, rbytes is updated but not rctime: # echo hello > a # getfattr -d -m ceph . | egrep 'bytes|ctime' ceph.dir.rbytes="6" ceph.dir.rctime="1521043831.0921836283" Modify the dir, rctime is updated: # touch b # getfattr -d -m ceph . | egrep 'bytes|ctime' ceph.dir.rbytes="6" ceph.dir.rctime="1521043861.09597651370"
I don't know when this regressed because I don't have any pre-luminous clusters left.
Related issues
History
#1 Updated by Zheng Yan about 6 years ago
- Status changed from New to Fix Under Review
#2 Updated by Patrick Donnelly about 6 years ago
- Subject changed from ceph.dir.rctime follows dir ctime not inode ctime to mds: ceph.dir.rctime follows dir ctime not inode ctime
- Assignee set to Zheng Yan
- Target version set to v13.0.0
- Backport set to luminous
- Component(FS) MDS added
#3 Updated by Patrick Donnelly almost 6 years ago
- Status changed from Fix Under Review to Pending Backport
#5 Updated by Nathan Cutler almost 6 years ago
- Copied to Backport #23750: luminous: mds: ceph.dir.rctime follows dir ctime not inode ctime added
#6 Updated by Nathan Cutler almost 6 years ago
- Status changed from Pending Backport to Resolved
#7 Updated by Dan van der Ster over 5 years ago
Sorry but I think we need to re-open this.
On v12.2.8 ceph-fuse client and server, we see the exact same behaviour (modifying file contents does not change parent dir rctime):
> touch rober3/test_file > getfattr -n ceph.dir.rctime rober3 # file: rober3 ceph.dir.rctime="1536159033.0992199201" > echo "content" >> rober3/test_file > getfattr -n ceph.dir.rctime rober3 # file: rober3 ceph.dir.rctime="1536159033.0992199201" > touch rober3/test_file2 > getfattr -n ceph.dir.rctime rober3 # file: rober3 ceph.dir.rctime="1536159060.0926720137" > echo "content" >> rober3/test_file > getfattr -n ceph.dir.rctime rober3 # file: rober3 ceph.dir.rctime="1536159060.0926720137"
#8 Updated by Patrick Donnelly over 5 years ago
Dan van der Ster wrote:
Sorry but I think we need to re-open this.
On v12.2.8 ceph-fuse client and server, we see the exact same behaviour (modifying file contents does not change parent dir rctime):
[...]
Dan, did you try calling fsync and/or waiting some time before checking the rctime? The rstats are propagated lazily and the client updates on the inode need sync'd before checking in any case.
#9 Updated by Dan van der Ster over 5 years ago
Patrick Donnelly wrote:
Dan van der Ster wrote:
Sorry but I think we need to re-open this.
On v12.2.8 ceph-fuse client and server, we see the exact same behaviour (modifying file contents does not change parent dir rctime):
[...]
Dan, did you try calling fsync and/or waiting some time before checking the rctime? The rstats are propagated lazily and the client updates on the inode need sync'd before checking in any case.
Hi Patrick. I called sync, waited 10 minutes, and still the parent dir (rober3) rctime doesn't move. I even remounted to make sure the contents were flushed. I also failed over both active mds's but that doesn't update the rctime.
Here are some additional tests. Note that updating the entire file contents (with >) does update the rctime of the parents. Append (>>) apparently does not.
[09:10]> mkdir -p a/b [09:11]> getfattr -n ceph.dir.rctime a # file: a ceph.dir.rctime="1536304279.09539255733" [09:11]> echo content > a/b/test_file [09:11]> getfattr -n ceph.dir.rctime a # file: a ceph.dir.rctime="1536304303.09489060210" [09:11]> echo content2 > a/b/test_file [09:11]> getfattr -n ceph.dir.rctime a # file: a ceph.dir.rctime="1536304313.09320979663"
All good so far. Let's try append.
[09:11]> echo content2 >> a/b/test_file [09:12]> getfattr -n ceph.dir.rctime a # file: a ceph.dir.rctime="1536304313.09320979663" [09:12]> ls -l a/b/ total 1 -rw-r--r--. 1 root root 18 Sep 7 09:12 test_file [09:12]> getfattr -n ceph.dir.rctime a # file: a ceph.dir.rctime="1536304313.09320979663" [09:12]> sleep 300 [09:19]> getfattr -n ceph.dir.rctime a # file: a ceph.dir.rctime="1536304313.09320979663"
With >> rctime never updates, even after sleeping 5 minutes and ls.
Now overwrite the file again:
[09:19]> ls -i a/b/test_file 1099992134357 a/b/test_file [09:22]> echo content > a/b/test_file [09:22]> ls -i a/b/test_file 1099992134357 a/b/test_file [09:22]> getfattr -n ceph.dir.rctime a # file: a ceph.dir.rctime="1536304956.09726248438"
When we > it updates the parents' rctime correctly.
#10 Updated by Dan van der Ster over 5 years ago
I just noticed that the qa test added in this PR doesn't check the >> case.
qa/workunits/fs: test for cephfs rstats
#11 Updated by Zheng Yan over 5 years ago
- Status changed from Resolved to Fix Under Review
- Target version changed from v13.0.0 to v14.0.0
#12 Updated by Patrick Donnelly over 5 years ago
- Related to Bug #35945: client: update ctime when modifying file content added
#13 Updated by Patrick Donnelly over 5 years ago
- Status changed from Fix Under Review to Resolved
Forked this new fix into a separate issue.