All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luis Henriques <lhenriques@suse.com>
To: Jeff Layton <jlayton@kernel.org>
Cc: Sage Weil <sweil@redhat.com>, "Yan, Zheng" <zyan@redhat.com>,
	Ilya Dryomov <idryomov@gmail.com>,
	ceph-devel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] ceph: initialize superblock s_time_gran to 1
Date: Fri, 28 Jun 2019 10:30:48 +0100	[thread overview]
Message-ID: <87a7e2dpkn.fsf@suse.com> (raw)
In-Reply-To: <c7fc812e444fee2fa7243044da5a48d1ad5b63ab.camel@kernel.org> (Jeff Layton's message of "Thu, 27 Jun 2019 12:10:25 -0400")

Jeff Layton <jlayton@kernel.org> writes:

> On Thu, 2019-06-27 at 15:44 +0000, Sage Weil wrote:
>> On Thu, 27 Jun 2019, Jeff Layton wrote:
>> > On Thu, 2019-06-27 at 14:51 +0100, Luis Henriques wrote:
>> > > Having granularity set to 1us results in having inode timestamps with a
>> > > accurancy different from the fuse client (i.e. atime, ctime and mtime will
>> > > always end with '000').  This patch normalizes this behaviour and sets the
>> > > granularity to 1.
>> > > 
>> > > Signed-off-by: Luis Henriques <lhenriques@suse.com>
>> > > ---
>> > >  fs/ceph/super.c | 2 +-
>> > >  1 file changed, 1 insertion(+), 1 deletion(-)
>> > > 
>> > > Hi!
>> > > 
>> > > As far as I could see there are no other side-effects of changing
>> > > s_time_gran but I'm really not sure why it was initially set to 1000 in
>> > > the first place so I may be missing something.
>> > > 
>> > > diff --git a/fs/ceph/super.c b/fs/ceph/super.c
>> > > index d57fa60dcd43..35dd75bc9cd0 100644
>> > > --- a/fs/ceph/super.c
>> > > +++ b/fs/ceph/super.c
>> > > @@ -980,7 +980,7 @@ static int ceph_set_super(struct super_block *s, void *data)
>> > >     s->s_d_op = &ceph_dentry_ops;
>> > >     s->s_export_op = &ceph_export_ops;
>> > >  
>> > > -   s->s_time_gran = 1000;  /* 1000 ns == 1 us */
>> > > +   s->s_time_gran = 1;
>> > >  
>> > >     ret = set_anon_super(s, NULL);  /* what is that second arg for? */
>> > >     if (ret != 0)
>> > 
>> > 
>> > Looks like it was set that way since the client code was originally
>> > merged. Was this an earlier limitation of ceph that is no longer
>> > applicable?
>> > 
>> > In any case, I see no need at all to keep this at 1000, so:
>> 
>> As long as the encoded on-write time value is at ns resolution, I 
>> agree!  No recollection of why I did this :(
>> 
>> Reviewed-by: Sage Weil <sage@redhat.com>
>
> Good enough for me. I went ahead and merged this into the testing
> branch. Assuming nothing breaks, this should make v5.3.

Awesome, thanks.  AFAICS it shouldn't break anything, specially because
the fuse client seems to be using ns resolution too.  But yeah
unexpected side-effects show up in unexpected ways :-)

Cheers,
-- 
Luis

WARNING: multiple messages have this Message-ID (diff)
From: Luis Henriques <lhenriques@suse.com>
To: Jeff Layton <jlayton@kernel.org>
Cc: Sage Weil <sweil@redhat.com>, "Yan\, Zheng" <zyan@redhat.com>,
	Ilya Dryomov <idryomov@gmail.com>,
	ceph-devel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] ceph: initialize superblock s_time_gran to 1
Date: Fri, 28 Jun 2019 10:30:48 +0100	[thread overview]
Message-ID: <87a7e2dpkn.fsf@suse.com> (raw)
In-Reply-To: <c7fc812e444fee2fa7243044da5a48d1ad5b63ab.camel@kernel.org> (Jeff Layton's message of "Thu, 27 Jun 2019 12:10:25 -0400")

Jeff Layton <jlayton@kernel.org> writes:

> On Thu, 2019-06-27 at 15:44 +0000, Sage Weil wrote:
>> On Thu, 27 Jun 2019, Jeff Layton wrote:
>> > On Thu, 2019-06-27 at 14:51 +0100, Luis Henriques wrote:
>> > > Having granularity set to 1us results in having inode timestamps with a
>> > > accurancy different from the fuse client (i.e. atime, ctime and mtime will
>> > > always end with '000').  This patch normalizes this behaviour and sets the
>> > > granularity to 1.
>> > > 
>> > > Signed-off-by: Luis Henriques <lhenriques@suse.com>
>> > > ---
>> > >  fs/ceph/super.c | 2 +-
>> > >  1 file changed, 1 insertion(+), 1 deletion(-)
>> > > 
>> > > Hi!
>> > > 
>> > > As far as I could see there are no other side-effects of changing
>> > > s_time_gran but I'm really not sure why it was initially set to 1000 in
>> > > the first place so I may be missing something.
>> > > 
>> > > diff --git a/fs/ceph/super.c b/fs/ceph/super.c
>> > > index d57fa60dcd43..35dd75bc9cd0 100644
>> > > --- a/fs/ceph/super.c
>> > > +++ b/fs/ceph/super.c
>> > > @@ -980,7 +980,7 @@ static int ceph_set_super(struct super_block *s, void *data)
>> > >     s->s_d_op = &ceph_dentry_ops;
>> > >     s->s_export_op = &ceph_export_ops;
>> > >  
>> > > -   s->s_time_gran = 1000;  /* 1000 ns == 1 us */
>> > > +   s->s_time_gran = 1;
>> > >  
>> > >     ret = set_anon_super(s, NULL);  /* what is that second arg for? */
>> > >     if (ret != 0)
>> > 
>> > 
>> > Looks like it was set that way since the client code was originally
>> > merged. Was this an earlier limitation of ceph that is no longer
>> > applicable?
>> > 
>> > In any case, I see no need at all to keep this at 1000, so:
>> 
>> As long as the encoded on-write time value is at ns resolution, I 
>> agree!  No recollection of why I did this :(
>> 
>> Reviewed-by: Sage Weil <sage@redhat.com>
>
> Good enough for me. I went ahead and merged this into the testing
> branch. Assuming nothing breaks, this should make v5.3.

Awesome, thanks.  AFAICS it shouldn't break anything, specially because
the fuse client seems to be using ns resolution too.  But yeah
unexpected side-effects show up in unexpected ways :-)

Cheers,
-- 
Luis

  reply	other threads:[~2019-06-28  9:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-27 13:51 [RFC PATCH] ceph: initialize superblock s_time_gran to 1 Luis Henriques
2019-06-27 14:41 ` Jeff Layton
2019-06-27 15:44   ` Sage Weil
2019-06-27 16:10     ` Jeff Layton
2019-06-28  9:30       ` Luis Henriques [this message]
2019-06-28  9:30         ` Luis Henriques

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a7e2dpkn.fsf@suse.com \
    --to=lhenriques@suse.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=idryomov@gmail.com \
    --cc=jlayton@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sweil@redhat.com \
    --cc=zyan@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.