Filesystem question

James Sutherland jas88 at cam.ac.uk
Thu Oct 12 20:50:17 GMT 2000


On Thu, 12 Oct 2000, Michael Tokarev wrote:

> Ulf Bertilsson wrote:
> > 
> []
> > >
> > > I've also noticed that simply browsing a directory in explorer
> > > causes just about every file in the directory to be opened to
> > > look for an icon to display.  Not very nice when you have files
> > > stored on tape.  )-:
> > >
> > > Some sort of fencepost or icon caching system perhaps would be nice.
> > 
> > I belive it will search for htm/.ini files for that folder as well.
> > No matter your tried turn all html crap off.
> > 
> > This matter for Win98/ME/2k, or maybe all Inet Explorer system.
> > 
> > May we address this in Samba ?
> 
> BTW, but is the OS filesystem cache was introduced for this!?
> I see that all unices around me (linux, solaris, sco) have very
> intelligent fs cache, that can work far better than samba implementation.
> For our site, I see disk access only when the first client accesses
> the directory, subcequent accesses takes results from fs cache
> (for all other clients also) -- there is no disk activity there.
> If samba will have its own cache implementation, then on this system
> this actually will _decrease_ performance, will require more additional
> resources (notably RAM) and decrease stability.  I recall that kernel
> know far more information about filesystem than samba can have, and
> kernel knows also available RAM size that can be used for caches,
> and it keeps cache only once while samba will keep it in each smbd
> process...

In the specific case of the stat() calls, I think Dave's patch (adding a
single item cache) looks reasonable: very little overhead in the
cache-miss case, and a big saving on cache-hits. If Samba is making
repeated stat() calls on a single file, this optimisation seems
reasonable.

Implementing a full-blown filesystem cache, on the other hand, would be
silly for the reasons you mention: the OS should be doing that anyway, so
any attempt on Samba's part would be counterproductive.


James.





More information about the samba-technical mailing list