On Wed, Apr 20, 2022 at 6:57 AM Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > On Wed, 2022-04-20 at 13:24 +0800, Xiubo Li wrote: > > Since the cephFS makes no attempt to maintain atime, we shouldn't > > try to update it in mmap and generic read cases and ignore updating > > it in direct and sync read cases. > > > > And even we update it in mmap and generic read cases we will drop > > it and won't sync it to MDS. And we are seeing the atime will be > > updated and then dropped to the floor again and again. > > > > URL: https://lists.ceph.io/hyperkitty/list/ceph-users@xxxxxxx/thread/VSJM7T4CS5TDRFF6XFPIYMHP75K73PZ6/ > > Signed-off-by: Xiubo Li <xiubli@xxxxxxxxxx> > > --- > > fs/ceph/addr.c | 1 - > > fs/ceph/super.c | 1 + > > 2 files changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c > > index aa25bffd4823..02722ac86d73 100644 > > --- a/fs/ceph/addr.c > > +++ b/fs/ceph/addr.c > > @@ -1774,7 +1774,6 @@ int ceph_mmap(struct file *file, struct vm_area_struct *vma) > > > > if (!mapping->a_ops->readpage) > > return -ENOEXEC; > > - file_accessed(file); > > vma->vm_ops = &ceph_vmops; > > return 0; > > } > > diff --git a/fs/ceph/super.c b/fs/ceph/super.c > > index e6987d295079..b73b4f75462c 100644 > > --- a/fs/ceph/super.c > > +++ b/fs/ceph/super.c > > @@ -1119,6 +1119,7 @@ static int ceph_set_super(struct super_block *s, struct fs_context *fc) > > s->s_time_gran = 1; > > s->s_time_min = 0; > > s->s_time_max = U32_MAX; > > + s->s_flags |= SB_NODIRATIME | SB_NOATIME; > > > > ret = set_anon_super_fc(s, fc); > > if (ret != 0) > > (cc'ing Greg since he claimed this...) Hmm? I don't think I've been in any atime discussions in years... > > I confess, I've never dug into the MDS code that should track atime, but > I'm rather surprised that the MDS just drops those updates onto the > floor. > > It's obviously updated when the mtime changes. The SETATTR operation > allows the client to set the atime directly, and there is an "atime" > slot in the cap structure that does get populated by the client. I guess > though that it has never been 100% clear what cap the atime should be > governed by so maybe it just always ignores that field? > > Anyway, I've no firm objection to this since no one in their right mind > should use the atime anyway, but you may see some complaints if you just > turn it off like this. There are some applications that use it. > Hopefully no one is running those on ceph. > > It would be nice to document this somewhere as well -- maybe on the ceph > POSIX conformance page? > > https://docs.ceph.com/en/latest/cephfs/posix/ > > -- > Jeff Layton <jlayton@xxxxxxxxxx> >
