> 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.
>> It will work quite reasonably for UNIX filesystems (except for
>> entries just below the mountpoint for which we currently have a
>> small bug in the updating of attributes), but may indeed be a
>> problem for VFAT-style filesystems that don't update directory
>> mtimes.
>>
>> Where are you BTW seeing persistent negative dentries? They
>> should never occur.
> To repeat my mail:
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.
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.
Cheers,
Trond
-
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/