All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Neil Brown <neilb@suse.de>
Cc: Chuck Lever <chuck.lever@oracle.com>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	"Patrick J. LoPresti" <lopresti@gmail.com>,
	Andi Kleen <andi@firstfloor.org>,
	linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Proposal: Use hi-res clock for file timestamps
Date: Wed, 18 Aug 2010 22:08:03 -0400	[thread overview]
Message-ID: <20100819020803.GA30151@fieldses.org> (raw)
In-Reply-To: <20100819105218.7620ec29@notabene>

On Thu, Aug 19, 2010 at 10:52:18AM +1000, Neil Brown wrote:
> On Thu, 19 Aug 2010 09:41:36 +1000
> Neil Brown <neilb@suse.de> wrote:
> 
> > So I agree that this is probably more of an issue for directories than for
> > files, and that implementing it just for directories would be a sensible
> > first step with lower expected overhead - just my reasoning seems to be a bit
> > different.
> 
> Just to be sure we are on the same page:
>   file_update_time would always refer to current_nfsd_time, but nfsd would
>   only update current_nfsd_time when a directory was examined (and the other
>   conditions were met).
> 
> 
> So my current thinking on how this would look - names have been changed:
> 
>  - global timespec 'current_fs_precise_time' is zeroed when
>    current_kernel_time moves backwards and is protected by a seqlock
> 
>  - current_fs_time would be
>          now = max(current_kernel_time(), current_fs_precise_time)
>          return timespec_trunc(now, sb->s_time_gran)
>    (with appropriate seqlock protection)
> 
>  - new function in fs/inode.c
>          get_precise_time(timestamp)

Odd name for something that returns nothing of interest;
bump_precise_time() might be closer?

And unique_time might be better than precise_time, since the property
we're asking for is that mtime on a changed file by new?  (Or
versioned_time?)

>                 cft = current_fs_time()
>                 if (timestamp == cft)
		     /*
		      * Make sure the next mtime stored will be
		      * something different from timestamp:
		      */
>                    write_seqlock()
>                    if cft == current_fs_precise_time
>                         current_fs_precise_time.tv_nsec++
>                    else if cft > current_fs_precise_time

What's the cft < current_fs_precise_time case?

--b.

>                         current_fs_precise_time = cft
>                    write_sequnlock()
>                 return timestamp
> 
>   - nfsd xdr response routine does
>              ts = inode->i_mtime
>              if (S_ISDIR(inode->i_mode))
>                 ts = get_precise_time(ts)
>              xdr_encode_timespec(ts)
> 
> 
> get_precise_time() probably needs a bit more subtlety to handle different
> s_time_gran values and possible races, but I think it is fairly close.
> 
> Then if we ever had an xstat or similar that could ask for precise
> timestamps, it just makes a similar call to get_precise_time.
> Also if we added code later to use a hires timer on hardware where it was
> efficient, get_precise_time could test for that and become a no-op
> 
> Yes, I should probably turn this into a patch ... maybe another day.
> 
> NeilBrown

WARNING: multiple messages have this Message-ID (diff)
From: "J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
To: Neil Brown <neilb-l3A5Bk7waGM@public.gmane.org>
Cc: Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,
	Alan Cox <alan-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>,
	"Patrick J. LoPresti"
	<lopresti-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org>,
	linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: Proposal: Use hi-res clock for file timestamps
Date: Wed, 18 Aug 2010 22:08:03 -0400	[thread overview]
Message-ID: <20100819020803.GA30151@fieldses.org> (raw)
In-Reply-To: <20100819105218.7620ec29@notabene>

On Thu, Aug 19, 2010 at 10:52:18AM +1000, Neil Brown wrote:
> On Thu, 19 Aug 2010 09:41:36 +1000
> Neil Brown <neilb-l3A5Bk7waGM@public.gmane.org> wrote:
> 
> > So I agree that this is probably more of an issue for directories than for
> > files, and that implementing it just for directories would be a sensible
> > first step with lower expected overhead - just my reasoning seems to be a bit
> > different.
> 
> Just to be sure we are on the same page:
>   file_update_time would always refer to current_nfsd_time, but nfsd would
>   only update current_nfsd_time when a directory was examined (and the other
>   conditions were met).
> 
> 
> So my current thinking on how this would look - names have been changed:
> 
>  - global timespec 'current_fs_precise_time' is zeroed when
>    current_kernel_time moves backwards and is protected by a seqlock
> 
>  - current_fs_time would be
>          now = max(current_kernel_time(), current_fs_precise_time)
>          return timespec_trunc(now, sb->s_time_gran)
>    (with appropriate seqlock protection)
> 
>  - new function in fs/inode.c
>          get_precise_time(timestamp)

Odd name for something that returns nothing of interest;
bump_precise_time() might be closer?

And unique_time might be better than precise_time, since the property
we're asking for is that mtime on a changed file by new?  (Or
versioned_time?)

>                 cft = current_fs_time()
>                 if (timestamp == cft)
		     /*
		      * Make sure the next mtime stored will be
		      * something different from timestamp:
		      */
>                    write_seqlock()
>                    if cft == current_fs_precise_time
>                         current_fs_precise_time.tv_nsec++
>                    else if cft > current_fs_precise_time

What's the cft < current_fs_precise_time case?

--b.

>                         current_fs_precise_time = cft
>                    write_sequnlock()
>                 return timestamp
> 
>   - nfsd xdr response routine does
>              ts = inode->i_mtime
>              if (S_ISDIR(inode->i_mode))
>                 ts = get_precise_time(ts)
>              xdr_encode_timespec(ts)
> 
> 
> get_precise_time() probably needs a bit more subtlety to handle different
> s_time_gran values and possible races, but I think it is fairly close.
> 
> Then if we ever had an xstat or similar that could ask for precise
> timestamps, it just makes a similar call to get_precise_time.
> Also if we added code later to use a hires timer on hardware where it was
> efficient, get_precise_time could test for that and become a no-op
> 
> Yes, I should probably turn this into a patch ... maybe another day.
> 
> NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2010-08-19  2:10 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-13 18:25 Proposal: Use hi-res clock for file timestamps Patrick J. LoPresti
2010-08-13 18:45 ` john stultz
2010-08-13 18:45   ` john stultz
2010-08-13 18:57   ` Patrick J. LoPresti
2010-08-13 19:09     ` john stultz
2010-08-13 19:09       ` john stultz
2010-08-13 20:53       ` Patrick J. LoPresti
2010-08-13 20:53         ` Patrick J. LoPresti
2010-08-14 16:45         ` Patrick J. LoPresti
2010-08-15  1:50         ` Bret Towe
2010-08-13 19:57     ` Jim Rees
2010-08-13 20:26       ` john stultz
2010-08-13 20:52         ` Jim Rees
2010-08-17 14:54 ` Andi Kleen
2010-08-17 14:54   ` Andi Kleen
2010-08-17 17:41   ` J. Bruce Fields
2010-08-17 17:41     ` J. Bruce Fields
2010-08-17 18:29     ` Andi Kleen
2010-08-17 18:29       ` Andi Kleen
2010-08-17 18:50       ` Patrick J. LoPresti
2010-08-17 18:50         ` Patrick J. LoPresti
2010-08-17 19:04       ` J. Bruce Fields
2010-08-17 19:18         ` Patrick J. LoPresti
2010-08-17 19:18           ` Patrick J. LoPresti
2010-08-17 19:39           ` Alan Cox
2010-08-17 19:39             ` Alan Cox
2010-08-17 19:29             ` J. Bruce Fields
2010-08-17 19:29               ` J. Bruce Fields
2010-08-17 19:52               ` Alan Cox
2010-08-17 19:52                 ` Alan Cox
2010-08-18  5:53               ` Neil Brown
2010-08-18  5:53                 ` Neil Brown
2010-08-18 14:46                 ` Patrick J. LoPresti
2010-08-18 14:46                   ` Patrick J. LoPresti
2010-08-18 17:32                 ` J. Bruce Fields
2010-08-18 17:32                   ` J. Bruce Fields
2010-08-18 18:15                   ` Chuck Lever
2010-08-18 18:15                     ` Chuck Lever
2010-08-18 23:41                     ` Neil Brown
2010-08-18 23:41                       ` Neil Brown
2010-08-19  0:52                       ` Neil Brown
2010-08-19  0:52                         ` Neil Brown
2010-08-19  2:08                         ` J. Bruce Fields [this message]
2010-08-19  2:08                           ` J. Bruce Fields
2010-08-19  2:44                           ` Neil Brown
2010-08-19  2:44                             ` Neil Brown
2010-08-19 22:46                             ` J. Bruce Fields
2010-08-19 22:46                               ` J. Bruce Fields
2010-08-18 23:47                   ` Neil Brown
2010-08-18 23:47                     ` Neil Brown
2010-08-18 17:50                 ` Andi Kleen
2010-08-18 17:50                   ` Andi Kleen
2010-08-18 18:54                   ` J. Bruce Fields
2010-08-18 19:25                     ` Andi Kleen
2010-08-18 19:30                       ` J. Bruce Fields
2010-08-17 19:34             ` Patrick J. LoPresti
2010-08-17 19:34               ` Patrick J. LoPresti
2010-08-17 19:54               ` Alan Cox
2010-08-17 19:43                 ` Patrick J. LoPresti
2010-08-17 19:43                   ` Patrick J. LoPresti
2010-08-17 19:45                   ` J. Bruce Fields
2010-08-17 19:45                     ` J. Bruce Fields
2010-08-18 18:12               ` J. Bruce Fields
2010-08-18 18:12                 ` J. Bruce Fields
2010-08-19  1:41                 ` john stultz
2010-08-19  1:41                   ` john stultz
2010-08-19  2:31                   ` J. Bruce Fields
2010-08-19  2:31                     ` J. Bruce Fields
2010-08-19  3:17                     ` john stultz
2010-08-19  3:17                       ` john stultz
2010-08-19 22:53                       ` J. Bruce Fields
2010-08-18 18:20       ` David Woodhouse
2010-08-18 18:20         ` David Woodhouse
2010-08-18 18:32         ` Patrick J. LoPresti
2010-08-18 18:32           ` Patrick J. LoPresti
2010-08-18 18:53         ` Andi Kleen

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=20100819020803.GA30151@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=andi@firstfloor.org \
    --cc=chuck.lever@oracle.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=lopresti@gmail.com \
    --cc=neilb@suse.de \
    /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.