On Thu, Aug 05, 1999 at 03:33:59PM +0200, Trond Myklebust wrote:
> >>>>> " " == Frank van Maarseveen <fvm@tasking.nl> writes:
>
> > 2.2.6-ac3 and other prior versions did not have this behavior
> > and to my knowledge no other UNIX client currently does (AFAIK
> > only OSF/1 3.2 NFS did something which is even more evil,
> > rendering it *completely* useless).
>
> 2.2.7 and below had a permanent 5second delay. This is worse behaviour
> than the 1 second delay.
That is not the case for 2.2.6-ac3 and 2.0.36 which have zero second
delays. Notice this excerpt from 2.2.6-ac3/fs/nfs/dir.c:
static int nfs_lookup_revalidate(struct dentry * dentry)
{
struct dentry * parent = dentry->d_parent;
struct inode * inode = dentry->d_inode;
int error;
struct nfs_fh fhandle;
struct nfs_fattr fattr;
/*
* If we don't have an inode, let's just assume
* a 5-second "live" time for negative dentries.
*/
if (!inode)
goto do_lookup;
The comment says 5 second but it clearly doesn't.
> With your test I see both the 30second delay (if you don't access the
> parent directory in any way) and the 1 second delay. No persistent
> negative dentries.
mount options: rw,nodev,rsize=8192,wsize=8192,nolock,retry=-1
client version result
2.0.36 ok ("nolock" is ignored)
2.2.6-ac3 ok
2.2.10-ac11 >60 sec persistence when <1sec loop
2.2.11-pre4 12..25 sec persistence when <1sec loop
Regarding pre4 you seem to be correct though I cannot reproduce the 30
seconds (I did 5 experiments). Still, I think it is questionable behavior
to lenghten the lifetime of a negative dentry when it is hit. Also, this
negative dentry caching makes it difficult (a bit undeterministic
and at least very slow) to signal a remote process by placing a marker
file on NFS. Yes, I know that that is silly programming but there are
a lot of silly programmers out there and in some situations it might
actually make sense to do it this way.
Regarding the caching of attributes for regular files I noticed the
following. On the server the command "ls >notfound" is repeatedly
executed (<1 sec loop). On the client "repstat notfound" is executed
(C source attached) and the mtime it reports changes with the following
interval (just tested, same mount options):
client version
2.0.36 3..4 sec conform the default for acregmin
2.2.6-ac3 1 sec
2.2.10-ac11 1 sec
2.2.11-pre4 1 sec
Another pre4 problem is that ls -l sometimes doesn't show one specific
file whereas stat() says otherwise. In this case ls -l was correct.
There are some other strange behaviors in 2.2.10-ac11 (incorrect
ESTALE for minutes, old versions of files being cached entirely)
but mostly they appear undeterministic because of little tweaks
in the kernel e.g. the mtime of the parent directory being older
than 15 mins (still present in pre4 fs/nfs/dir.c):
static inline int nfs_dentry_force_reval(struct dentry *dentry, int flags)
{
struct inode *inode = dentry->d_inode;
unsigned long timeout = NFS_ATTRTIMEO(inode);
/*
* If it's the last lookup in a series, we use a stricter
* cache consistency check by looking at the parent mtime.
*
* If it's been modified in the last hour, be really strict.
* (This still means that we can avoid doing unnecessary
* work on directories like /usr/share/bin etc which basically
* never change).
*/
if (!(flags & LOOKUP_CONTINUE)) {
long diff = CURRENT_TIME - dentry->d_parent->d_inode->i_mtime;
if (diff < 15*60)
timeout = 0;
}
return time_after(jiffies,dentry->d_time + timeout);
}
In this case the comment contains a bug: it's not an hour but
only 15 minutes. When I have something reproducible for pre4
I'll mail it to the list.
> If this is a major problem, I suggest rather that we fine-tune the
> delays, not that we remove support for negative dentry caching. Linus'
> typical example was an NFS-shared /usr/share partition (or any NFSroot
> system): if you have several users searching for a file in such a
> tree, turning off caching of negative dentries can lead to storms of
> unnecessary NFS_LOOKUP calls.
To me this appears as a no win situation. I wonder if one second really
helps that much. On the other hand more than a few seconds is likely
to hurt in many situations. So, why not making this configurable and
creating something like a /proc/sys/nfs/neg-dentry-timeout to set it or
disable it? The least which could be done is to disable negative dentry
caching entirely for NFS when acregmin is set to zero (disabling acreg).
Regards,
-- Frank--kXdP64Ggrk/fb43R Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="repstat.c"
#include <stdio.h> #include <time.h> #include <string.h> #include <stdlib.h> #include <errno.h> #include <unistd.h> #include <sys/types.h> #include <sys/stat.h> #include <sys/file.h>
void main(int argc, char *argv[]) { char *file; unsigned long us; struct stat st;
if ((argc > 1 && argv[1][0] == '-') || argc > 3) { printf("Usage: repstat [file [micro-seconds-delay]]\n"); printf(" default delay = 700000 us.\n"); exit(0); } file = argc >= 2 ? argv[1] : "."; us = argc == 3 ? atol(argv[2]) : 700000; while (1) { if (stat(file, &st) == -1) { printf("%s: %s\n", file, strerror(errno)); } else { printf("%s: %s", file, ctime(&st.st_mtime)); } usleep(us); } }
--kXdP64Ggrk/fb43R--
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/