multiple smbd's ?

[R.Oehler at GDImbH.com]

On 04-Jan-2002 David Collier-Brown wrote:
>> When I do just two copies from one client to two different
>> server-media, then the copies of this client get stuck because
>> there is only one server smbd for two only alternatingly
>> accessible client-media.
>> 
>> Are there solutions availlable?
> 
>       There are, almost by definition, a number of
>       possible solutions to HSM thrashing.
> 
>       The obvious one is use a hierarchical storage
>       manager that doesn't thrash (;-))  The ones I'm
>       familiar with all have caches, which can be
>       tuned to minimize the problem.
The problem is, that our jukebox system is not intended
to be used like common NAS-systems. It could be used
as a sort of HSM, but the main usage is to store data on
WORMs in a way that is safe/secure against malicious tampering 
of the data. So the main point is to avoid cacheing as possible.
(At least the client-close() has to guarantee that the
file is safely on the server-medium.) This forbids internal
HSM-ing on the server.
> 
>       The second approach is to have the application
>       using the hsm to read the whole file, thus
>       implicitly caching it.  This can be done
>       in Samba, by writing a vfs module that issues
>       a read larger than the expected file size.
>       This will cache the data in a combination of
>       memory and swap.
Sounds OK, as long as the client won't run into timeouts.
Does such a module exist?
> 
>       The third is to use cachefs in front of the
>       hsm. This assumes the OS has a vfsswitch and
>       a caching filesystem.
Does cachefs exist for linux?
> 
>       Applying the NFS-like solution of having a pool
>       of service processes/threads/whatevers would
>       require a **substantial** change to Samba, and
>       provide only a moderate improvement, as it's
>       basically a work-around, not a solution to the
>       underlying problem.
That depends on the point of view. When the NAS-box is
seen as a unit, it just has to guarantee smooth flow on 
every open data connection. It could do this
internally by spooling to RAM by multiple daemons (nfsd
pumps data to the buffer cache) or by spooling data to a 
harddisk and using a copy-process to move it to the jukebox.

I prefer the NFS-way, because then the various syncronisations
between the "cache-stages" are completely and trivially handled 
by the kernel.


Regards,
        Ralf

 -----------------------------------------------------------------
|  Ralf Oehler
|  GDI - Gesellschaft fuer Digitale Informationstechnik mbH
|
|  E-Mail:      R.Oehler at GDImbH.com
|  Tel.:        +49 6182-9271-23 
|  Fax.:        +49 6182-25035           
|  Mail:        GDI, Bensbruchstraße 11, D-63533 Mainhausen
|  HTTP:        www.GDImbH.com
 -----------------------------------------------------------------

time is a funny concept