Fixed: OpLocks caused the corruptions/slowness (Was: How Samba let us down)
Chris de Vidal
cdevidal at yahoo.com
Thu Oct 24 13:29:54 GMT 2002
--- Jay Ts <jay at jayts.cx> wrote:
> > * The corruption was missing records. It would
> > interrupt the print process and the Opus analysis
> > indicated hundreds of records were missing. It
> > happen in random places in print files (hundreds
> > megs to gigs in size), and seldomly would not
> > at all.
> I still don't understand! Ok, the files are not
> on the Samba host, they are printed through an NT
> print server, correct?
Through a variety of print servers to a variety of
printers, from large laser printers that print to
spools of paper to washing machine-sized HP LaserJet
printers. One of the queues is on NT, one (or more)
is on Netware.
> So are you saying that it's
> files served by Samba that are being sent to the
> printer, and that's where you're losing data?
I think the corruption is happening in the processing
of the large DB files on the new server.
> [ok I just re-read your original post...] You said
> that the Samba server is used as a "print spooling
> area". Can you elucidate?
> It seems you are offering a Samba
> file share, which is used by another system(s?) for
> NT's printer spool files.
Nothing in NT is configured to spool to that server,
but somewhere along the line, files are put on that
> There are some "dangerous" smb.conf parameters, and
> AFAIK (maybe not infinitely far ;) the Samba Team
> have documented that they can be misused in a way
> that can result in corruption.
> Did you check the manual page for smb.conf(5),
> especially for the parameters having to do with
> locking, to check that you weren't doing anything
We scoured every reference to locking in the manpages,
online documents, and in /usr/share/doc, which is why
I think if there is a known caveat, it ought to appear
> Just to head off another bunch of comments from the
> Samba Team,
> please understand that just because you get a
> message from Windows
> that says your database is *possibly* corrupt, it
> doesn't mean
> that your database *is* corrupt. OK? ;-)
We *really* did see corruption, though.
> > We might reenable kernel then
> > regular then level2 oplocks later to see if it was
> > just one particular type.
> Pretty please! I'm really curious to find out
> exactly what was happening.
I'd be happy to let the group know. I'm not positive
we'll reenable anything but kernel oplocks, though.
We have work to do.
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
More information about the samba-technical