On Sun, 14 May 2000, Petr Vandrovec wrote:
> On Sun, May 14, 2000 at 04:37:46AM -0400, Alexander Viro wrote:
> > devfs_unlink() does - especially in free_dentries(). Or you can get
> > your kicks looking at the crap (sorry, Petr, but it _is_ crap - populating
> > dcache really shouldn't be done by readdir()) in ncp_readdir().
> Hi Alexander,
> is implementation wrong or whole idea (some race? Do not forget that it
> is network filesystem, so only troubles which cannot happen due to other
> machines count)? Netware does not have hardlinks (without BIG effort) and
> reading directory from server offer all data needed for constructing inode.
> By creating real dentries/inodes during readdir (and caching them for some
> time period) some operations are now twice as fast as before - for example
> unlinking directories.
> > Al, BKernelJanitorFH
> Petr Vandrovec
> [EMAIL PROTECTED]
>
> P.S.: Original idea was to cache only readdir data from server, but it
> could consume twice as much memory - once in pagecache and second time
> when real dentries/inodes get created. And ncp_lookup was forced to search
> pagecache before doing server lookup... So populating dentry tree from
> readdir looked perfect to me. It is not?
It is not. For a lot of reasons, starting from pressure on dcache LRU
(readdir() on ncpfs -> lots of stuff fed into dcache -> very long LRU ->
next dcache flush takes out former LRU population) and including the
problems with making dcache SMP-safe.
BTW, am I right assuming that volume number + dirExt... thing identify the
object in unique way? If they do - I have a trick that can get rid of
double memory use _and_ avoid dcache pollution/need of very messy locking.
