Project

General

Profile

Bug #23380

mds: ceph.dir.rctime follows dir ctime not inode ctime

Added by Dan van der Ster 9 months ago. Updated 3 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
03/15/2018
Due date:
% Done:

0%

Source:
Community (user)
Tags:
Backport:
luminous
Regression:
Yes
Severity:
2 - major
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(FS):
MDS
Labels (FS):
Pull request ID:

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

Related to fs - Bug #35945: client: update ctime when modifying file content Resolved 09/11/2018
Copied to fs - Backport #23750: luminous: mds: ceph.dir.rctime follows dir ctime not inode ctime Resolved

History

#1 Updated by Zheng Yan 9 months ago

  • Status changed from New to Need Review

#2 Updated by Patrick Donnelly 9 months 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 8 months ago

  • Status changed from Need Review to Pending Backport

#5 Updated by Nathan Cutler 8 months ago

  • Copied to Backport #23750: luminous: mds: ceph.dir.rctime follows dir ctime not inode ctime added

#6 Updated by Nathan Cutler 7 months ago

  • Status changed from Pending Backport to Resolved

#7 Updated by Dan van der Ster 3 months 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 3 months 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 3 months 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 3 months 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 3 months ago

  • Status changed from Resolved to Need Review
  • Target version changed from v13.0.0 to v14.0.0

#12 Updated by Patrick Donnelly 3 months ago

  • Related to Bug #35945: client: update ctime when modifying file content added

#13 Updated by Patrick Donnelly 3 months ago

  • Status changed from Need Review to Resolved

Forked this new fix into a separate issue.

Also available in: Atom PDF