[Samba] Weird behaviour opening pdf files (and maybe others)

[Alexandre]

Hi,

I had to review a samba setup recently where people experienced strange
things.
Basically they more from a solaris on phisical machines environment
(locally hosted) running an old version of samba (2.x or even 1.x) to a Red
Hat virtualized environement runing 3.6 (remotely hosted).
The link between clients and server is really good (2x100Mb/s fiber) and
browsing shares and opening office document is pretty good.
However they are sharing some PDF files (half a MB each) and those are
taking really long to open. When opened with Adobe reader from a windows
machine, the PDF load by "slices". Some paragraph loads, and then another,
and then another...
Same behaviour can be seen with a linux client and xpdf (evince just takes
ages to open the pdf).
Raw transfers and copies (smbclient and windows drag and drop) works nicely.

The interesting bit:

The PDF files are actually stored on an NFS export on the EMC SAN storage.
If I move the PDF files to another samba share with the same options but on
a local filesystem, then the PDF loads nicely.

If I monitor the network traffic while opening a PDF file on the NFS
export, I can see a lot of very short "smb read andX responses" (256 bytes
long) and the total transfer size for a 500KB file is around 6MB.

If I monitor the network traffic while opening a PDF file on a local
filesystem, I can see big "smb read andX responses" (65536 bytes as stated
in smb.conf with "max xmit") and total transfer size is about equal to the
file size.

the NFS export is mounted on the samba server using options:
rw,noatime,nodiratime,bg,soft,rsize=65536,wsize=65536,nfsvers=3,proto=tcp,nocto,noacl,noac,int,nolock


The cubersome bit:

At this point you can easily blame NFS (which i did) and claim sharing NFS
exports via samba is just not a good idea (probably right anyway). BUT... a
windows client that sits next to the samba server can open the problematic
PDF files without anyproblem, even if they are stored on the nfs exports!

I'd be interested to know if anybody already had the kind of problem and
how they troubleshot/fixed it. Also if you have some idea where to look at
just let me know.
Finally, I have tried to find clear statement about sharing NFS exports via
samba and wether or not it is suposed to work or what are the limitations.
What's your opinion?

Regards, Alex

[Alexandre]

Actually I have "kernel oplock = yes" set in the global section.

I don't know if it helps but I can provide network capture if needed...

Post by Alexandre

Post by Alexandre
Finally, I have tried to find clear statement about sharing NFS

exports via

Post by Alexandre
samba and wether or not it is suposed to work or what are the

limitations.

Post by Alexandre
What's your opinion?

Sounds to me like no oplocks are being granted on the NFS share
export. That'd do it.

"kernel oplocks = no" ?
Volker

[Alexandre]

I also set "veto oplock files = /*.pdf/" at share level

Post by Alexandre
Actually I have "kernel oplock = yes" set in the global section.
I don't know if it helps but I can provide network capture if needed...

Post by Alexandre

Post by Alexandre
Finally, I have tried to find clear statement about sharing NFS

exports via

Post by Alexandre
samba and wether or not it is suposed to work or what are the

limitations.

Post by Alexandre
What's your opinion?

Sounds to me like no oplocks are being granted on the NFS share
export. That'd do it.

"kernel oplocks = no" ?
Volker

[Alexandre]

I think this was the previous settings.
The smb.conf man page seemed to recommend oportunistic locking when using
NFS with samba so I added both of this options myself. But reading through
the man again I may have missunderstood it. I'm going to give your
suggestion a try and let you know.

Thank you.

Post by Alexandre
I also set "veto oplock files = /*.pdf/" at share level

Post by Alexandre
Actually I have "kernel oplock = yes" set in the global section.

Both those "kernel oplock = yes", "veto oplock files = /*.pdf/"
are exactly what you *don't* want :-).
As Volker said, set "kernel oplocks = no" and remove
the "veto oplock files" line and you might actually
*get* oplocks on these files.