mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ion Badulescu <ionut@badula.org>
To: "Vivek Goyal" <vivek.goyal@wipro.com>
Cc: <trond.myklebust@fys.uio.no>, <indou.takao@jp.fujitsu.com>,
	<ezk@cs.sunysb.edu>, <viro@math.psu.edu>, <davem@redhat.com>,
	<nfs@lists.sourceforge.net>, <linux-kernel@vger.kernel.org>
Subject: Re: [NFS] Disabling Symbolic Link Content Caching in NFS Client
Date: Mon, 2 Jun 2003 16:37:23 -0400	[thread overview]
Message-ID: <200306022037.h52KbNVh012849@buggy.badula.org> (raw)
In-Reply-To: <2BB7146B38D9CA40B215AB3DAAE24C080BA4F3@blr-m2-msg.wipro.com>

On Wed, 28 May 2003 16:39:36 +0530, Vivek Goyal <vivek.goyal@wipro.com> wrote:

> I was following previous discussions in the mailing list and found that
> caching mechanism affected hlfsd behavior. It looks like the problem was
> resolved by updating mtime on every access. But still caching will lead
> to a problem if two accesses are taking place in same jiffy.

Yes, because the the nfs client is broken in this respect. noac 
should mean noac, but the nfs client will still cache attributes if the 
second access happens within the same jiffy as the previous access which 
updated the attribute cache.

Replacing a couple of time_after() calls with time_after_eq() calls 
fixes the issue, at least for hlfsd. Of course, running with noac might 
be very much unacceptable if all you want is to avoid caching symlinks.

> We are considering following design strategy to implement the parameter.
> 
> 1. Make nfs_symlink_caching dynamically tunable using /proc and sysctl
> interface.

No. Do it on a per-mount basis, like the other OS's do.

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
            than to open it and remove all doubt.

  reply	other threads:[~2003-06-02 20:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-28 11:09 Vivek Goyal
2003-06-02 20:37 ` Ion Badulescu [this message]
2003-06-02 21:48   ` [NFS] " Trond Myklebust
2003-06-02 21:56   ` Trond Myklebust
2003-06-03 13:20 Vivek Goyal
2003-06-03 16:05 ` Trond Myklebust
2003-06-03 13:33 Edward Hibbert
2003-06-03 14:46 ` Frank van Maarseveen
2003-06-03 16:08 ` Trond Myklebust

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=200306022037.h52KbNVh012849@buggy.badula.org \
    --to=ionut@badula.org \
    --cc=davem@redhat.com \
    --cc=ezk@cs.sunysb.edu \
    --cc=indou.takao@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nfs@lists.sourceforge.net \
    --cc=trond.myklebust@fys.uio.no \
    --cc=viro@math.psu.edu \
    --cc=vivek.goyal@wipro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®