From: Trond Myklebust <Trond.Myklebust@netapp.com>
To: Peter Staubach <staubach@redhat.com>
Cc: chucklever@gmail.com, NFS list <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH V2] make "noac" and "actimeo=0" work correctly
Date: Thu, 10 Jul 2008 15:29:44 -0400 [thread overview]
Message-ID: <1215718184.7126.44.camel@localhost> (raw)
In-Reply-To: <487649AE.1090909@redhat.com>
On Thu, 2008-07-10 at 13:41 -0400, Peter Staubach wrote:
> > include/linux/jiffies.h claims it handles jiffy wrapping correctly.
> > Why isn't time_in_range() sufficient if 'c' has wrapped? If it isn't,
> > should you fix time_in_range() too?
> >
> >
>
> Clearly, time_in_range() is not sufficient if the 'c' has
> wrapped. It only tests to see if a >=b and a <= c. If 'c'
> is less than 'b', then time_in_range() will return false.
Hmm... The actual test in the current time_in_range() should be
((long)b - (long)a) <= 0) && ((long)a - (long)c) <= 0
Which is _not_ the same as testing for a>=b && a<=c in the case of a
sign wrap. Can you show me a case where we might have a problem?
The only case I can think of is if
((long) c - (long) b) < 0
(IOW: if the range itself is too large to fit into a signed long). I
can't imagine that we will ever find ourselves in that situation.
> The change, which makes attrtimeo=0 work for free, is to figure out
> that if the attrtimeo is N, then the attribute cache is valid from
> time, T, to T + N - 1, not T + N. Thus, the current attribute
> cache implementation is off by one because the attribute cache
> should expire at time, T + N. The time_in_range() macro was handy
> and looked right, but wasn't quite right for the desired semantics.
>
> Adding tests to check to see if b and c are equal is tuning for
> the wrong case, I think. I believe that the majority of file
> systems are not mounted with "noac" or "actimeo=0", so the extra
> test would just be overhead for the common case.
I agree with this.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
next prev parent reply other threads:[~2008-07-10 19:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-10 20:52 [PATCH] make "noac" and "actimeo=0" work correctly Peter Staubach
2008-07-08 16:08 ` [PATCH V2] " Peter Staubach
2008-07-10 15:58 ` Chuck Lever
[not found] ` <76bd70e30807100858g58fbf454uc9331035a2bbf264-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-10 17:41 ` Peter Staubach
2008-07-10 18:55 ` Chuck Lever
[not found] ` <76bd70e30807101155l226c1cceh24ca17157cb454bf-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-10 19:23 ` Peter Staubach
2008-07-10 19:31 ` Chuck Lever
2008-07-10 19:29 ` Trond Myklebust [this message]
2008-07-11 20:14 ` Peter Staubach
2008-07-11 20:19 ` Trond Myklebust
2008-07-11 20:24 ` Peter Staubach
2008-12-05 21:37 ` [PATCH V3] optimize attribute timeouts for "noac" and "actimeo=0" Peter Staubach
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=1215718184.7126.44.camel@localhost \
--to=trond.myklebust@netapp.com \
--cc=chucklever@gmail.com \
--cc=linux-nfs@vger.kernel.org \
--cc=staubach@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.