Bug #23380: mds: ceph.dir.rctime follows dir ctime not inode ctime - CephFS - Ceph

Actions

Copy link

Bug #23380

closed

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

Added by Dan van der Ster about 6 years ago. Updated over 5 years ago.

Status:

Resolved

Priority:

Normal

Assignee:

Zheng Yan

Category:

Target version:

Ceph - v14.0.0

% Done:

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:

Crash signature (v1):

Crash signature (v2):

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 2 (0 open — 2 closed)

Actions

Copy link

Updated by Zheng Yan about 6 years ago

Status changed from New to Fix Under Review

https://github.com/ceph/ceph/pull/21039

Actions

Copy link

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

Actions

Copy link

Updated by Patrick Donnelly about 6 years ago

Status changed from Fix Under Review to Pending Backport

Actions

Copy link

Updated by Nathan Cutler about 6 years ago

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

Actions

Copy link

Updated by Nathan Cutler almost 6 years ago

Status changed from Pending Backport to Resolved

Actions

Copy link

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"

Actions

Copy link

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.

Actions

Copy link

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.

Actions

Copy link

#10