FrameMaker/SAMBA issue
Simo Sorce
simo.sorce at polimi.it
Thu Mar 22 11:22:07 GMT 2001
Would it be a caching issue?
Tiffs are generally very big images (many megabytes) some times.
Do NT set some property about caching when serving files?
just a tought
On Thu, 22 Mar 2001, Christopher R. Hertel wrote:
> > Hello,
> >
> > Over the last week or so I have been
> > trying to
> > discover exactly what the issue is with Adobe
> > FrameMaker and SAMBA. I think I may be able to
> > put my finger on it now. I hope someone of the
> > SAMBA developer team will be able to take a look
> > at the code and correct this if it is in fact a
> > bug in the code.
> >
> > Users working on FrameMaker projects served from a
> > *NIX box running SAMBA, (only tested this on IRIX,
> > linux and Solaris) experience sub acceptable
> > performance with page refresh/loads. The same
> > projects served from a native NT file server
> > allowed users to experience near local
> > performance. The same projects served from the
> > same *NIX box but via NFS (NFS service installed
> > on NT client) seen near local performance.
> > Indicating perhaps an application issue.
> >
> > The image format of choice by FrameMaker folk tend
> > to be TIFFs. SAMBA it seems has a hard time
> > opening Tiffs in an efficient manner. Replace the
> > TIFFs with almost any other image file format and
> > performance shoots threw the roof even if they are
> > of the same size. (thankfully microsloth didn't
> > use tiffs in any of the benchmarks they
> > sponsored). In a high debug mode you can see
> > SAMBA stuck in a routine that it seems to execute
> > several times per TIF file. I also noticed if you
> > reduce the TIF to 256 shades of gray things speed
> > up considerably as well.
>
> Which routine? That would help a lot.
>
> My completely wild guess is that the reading of a TIFF file involves a lot
> of random access, and that we are crossing some sort of buffer boundary.
>
> I do not know how data is stored in a TIFF file, but the fact that a
> change in pixel depth would change the read characteristics suggests to
> me that deeper pixel depths require more reads on Samba's part.
>
> Very, very wild guess.
>
> Chris -)-----
>
>
--
Simo Sorce - Linux Systems Consultant
E-mail: simo.sorce at polimi.it
Tel: +39 0348 7149179 - Fax: +39 02 700442399
-----------------------------------------------------------------
Be happy, use Linux!
More information about the samba-technical
mailing list