Project

General

Profile

Actions

Bug #36171

open

mds: ctime should not use client provided ctime/mtime

Added by Patrick Donnelly over 5 years ago. Updated 6 months ago.

Status:
New
Priority:
Urgent
Assignee:
-
Category:
-
Target version:
-
% Done:

0%

Source:
Development
Tags:
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(FS):
Client, MDS, kceph
Labels (FS):
task(intern), task(medium)
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

Otherwise, you can set a ctime that is far in the future and it cannot be rolled back.

pdonnell@senta02 ~/ceph$ cd /home/pdonnell/mnt/tmp.9cYgpRTGXD
pdonnell@senta02 ~/mnt/tmp.9cYgpRTGXD$ mkdir foo
pdonnell@senta02 ~/mnt/tmp.9cYgpRTGXD$ touch foo/bar
pdonnell@senta02 ~/mnt/tmp.9cYgpRTGXD$ getfattr -n ceph.dir.rctime foo
# file: foo
ceph.dir.rctime="1537838662.09897717617" 
pdonnell@senta02 ~/mnt/tmp.9cYgpRTGXD$ stat foo/bar
  File: 'foo/bar'
  Size: 0               Blocks: 0          IO Block: 4194304 regular empty file
Device: 2ch/44d Inode: 1099511627777  Links: 1
Access: (0640/-rw-r-----)  Uid: ( 1163/pdonnell)   Gid: ( 1163/pdonnell)
Access: 2018-09-24 21:24:22.893455885 -0400
Modify: 2018-09-24 21:24:22.893455885 -0400
Change: 2018-09-24 21:24:22.897717617 -0400
 Birth: -
pdonnell@senta02 ~/mnt/tmp.9cYgpRTGXD$ touch foo/derp
pdonnell@senta02 ~/mnt/tmp.9cYgpRTGXD$ date +%s
1537838726
pdonnell@senta02 ~/mnt/tmp.9cYgpRTGXD$ getfattr -n ceph.dir.rctime foo
# file: foo
ceph.dir.rctime="1537838725.0981013223" 

pdonnell@senta02 ~/mnt/tmp.9cYgpRTGXD$ touch -m --date='Jan 01 2022' foo/derp
pdonnell@senta02 ~/mnt/tmp.9cYgpRTGXD$ getfattr -n ceph.dir.rctime foo
# file: foo
ceph.dir.rctime="1641013200.090" 

pdonnell@senta02 ~/mnt/tmp.9cYgpRTGXD$ rm foo/derp
pdonnell@senta02 ~/mnt/tmp.9cYgpRTGXD$ getfattr -n ceph.dir.rctime foo
# file: foo
ceph.dir.rctime="1641013200.090" 

Partially caused by 60f73cde4e04be2685eaf7cd04e03c045e1f9977 and #35945.

I think the right approach here is to have the client set its own ctime so that it's locally useful but not to transmit it to the MDS. The MDS always uses its own clock to update the ctime/rctime. This means from the client's perspective that the ctime changes twice for a single metadata operation but I think that's acceptable. The standards provide no guarantees or guidance on this.

Actions #1

Updated by Patrick Donnelly over 5 years ago

  • Subject changed from mds: ctime should not use mtime value to mds: ctime should not client provided ctime/mtime
Actions #2

Updated by Patrick Donnelly over 5 years ago

  • Subject changed from mds: ctime should not client provided ctime/mtime to mds: ctime should not use client provided ctime/mtime
  • Status changed from New to In Progress
  • Assignee set to Patrick Donnelly
Actions #3

Updated by Patrick Donnelly over 5 years ago

  • Status changed from In Progress to Fix Under Review
Actions #4

Updated by Patrick Donnelly about 5 years ago

  • Target version changed from v14.0.0 to v15.0.0
Actions #5

Updated by Patrick Donnelly about 5 years ago

  • Status changed from Fix Under Review to In Progress
  • Pull request ID set to 24277
Actions #6

Updated by Patrick Donnelly about 4 years ago

  • Target version deleted (v15.0.0)
Actions #7

Updated by Malcolm Haak about 4 years ago

I think the right approach here is to have the client set its own ctime so that it's locally useful but not to transmit it to the MDS. The MDS always uses its own clock to update the ctime/rctime. This means from the client's perspective that the ctime changes twice for a single metadata operation but I think that's acceptable. The standards provide no guarantees or guidance on this.

I totally disagree for the mtime case. This breaks rsync and lots of other applications expected behaviour. At least for mtime anyway. Ctime this is the sane behaviour.

mtime should be arbitrary. I've had issues with applications freak out when its in the future but it is technically 'valid'. But I've also encountered workloads where it gets set into the future so it gets left alone until after that date. (I work in HPC and scientists are odd sometimes). But the real issue is if I can't update mtime, rsync can't cheat and use mtimes to detect file changes. That makes many backups sad.

Anyway long story short, mtime should ALWAYS be whatever weird thing the client sets it to. Ctime is less important.

Thanks.

Actions #8

Updated by Greg Farnum about 4 years ago

Yeah, we previously assigned mtimes from the MDS and it was a disaster. That's not something we'll be going back to!

I'm less sure about ctimes but I don't think applications outside of samba tend to care about those much...

Actions #9

Updated by Zheng Yan about 4 years ago

see https://github.com/ceph/ceph/pull/32126. that commit add 'dirty_from' field to rstat, which is mds time. mds can use 'dirty_from' to decide if rctime should be set to a smaller value.

Actions #10

Updated by Dan van der Ster over 3 years ago

IMHO ctime should always be `ceph_clock_now()` rather than any time from the client.

Here's an XFS demo. Note how Change time is the clock when a change is made, not related to the arbitrary Modify time of the file:

# touch asdf
# stat asdf
  File: ‘asdf’
  Size: 0             Blocks: 0          IO Block: 4096   regular empty file
Device: fc01h/64513d    Inode: 25166519    Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Context: unconfined_u:object_r:user_tmp_t:s0
Access: 2020-10-15 14:33:51.874524960 +0200
Modify: 2020-10-15 14:33:51.874524960 +0200
Change: 2020-10-15 14:33:51.874524960 +0200
 Birth: -
# touch -t 202501010000 asdf 
# stat asdf
  File: ‘asdf’
  Size: 0             Blocks: 0          IO Block: 4096   regular empty file
Device: fc01h/64513d    Inode: 25166519    Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Context: unconfined_u:object_r:user_tmp_t:s0
Access: 2025-01-01 00:00:00.000000000 +0100
Modify: 2025-01-01 00:00:00.000000000 +0100
Change: 2020-10-15 14:34:00.520475964 +0200
 Birth: -

Actions #11

Updated by Patrick Donnelly 6 months ago

  • Status changed from In Progress to New
  • Assignee deleted (Patrick Donnelly)
  • Backport deleted (mimic,luminous)
  • Labels (FS) task(intern), task(medium) added
  • Labels (FS) deleted (task(easy))
Actions

Also available in: Atom PDF