Our more serious issue: two kinds of Samba read corruption

BG - Ben Armstrong BArmstrong at dymaxion.ca
Mon Sep 27 18:33:24 GMT 2004


On Thu, 2004-09-23 at 14:17 -0300, BG - Ben Armstrong wrote:
> We have been noticing that using MS Wordpad, COPY, or other means to
> read the contents of a file, most of the time the file is successfully
> retrieved, but sometimes it returns empty.  This happens on a fairly
> regular basis, so with proper direction, we ought to be able to "catch
> it in the act" and report more details here.  So, what should we be
> looking for?  Should our log levels be elevated, and if so, how high?
> Is there anything else we can do to make this problem more visible?

With regards to this problem, today we collected some observations
during an incident:

- backup/ignore=interlock made of all .tdb files
- show process/acc on the user's smbd process
- show device/files for files open by the user's smbd process
- dir (on the Windows client) showing zero blocks for most (but not all)
files in the "problem" directory
- dir (on the Windows client) after killing off the user's smbd process
showing that all files in the "problem" directory now all have expected
sizes

I will provide all of these in a zip archive to JYC for closer
examination.  For the rest of us, I include below the show process &
show device output, in case anything looks suspicious:

27-SEP-2004 14:54:26.45   User: SYSTEM           Process ID:   0001DA0F
                          Node: DYMA             Process name: "SMBD_DMPCXP_DA0"

Accounting information:
 Buffered I/O count:    193317  Peak working set size:      14640
 Direct I/O count:       44366  Peak virtual size:         184880
 Page faults:             1009  Mounted volumes:                0
 Images activated:           3
 Elapsed CPU time:          0 00:01:53.01
 Connect time:              0 08:54:26.07

Soft CPU Affinity: off

SMBD_DMPCXP_DA0 0001DA0F  [SYSCOMMON.SYSEXE]RIGHTSLIST.DAT;3
SMBD_DMPCXP_DA0 0001DA0F  [SAMBA.VAR.LOCKS]MESSAGES.TDB;1
SMBD_DMPCXP_DA0 0001DA0F  [SAMBA.BIN]SMBD_STARTUP.COM;9
SMBD_DMPCXP_DA0 0001DA0F  [SAMBA.BIN]SMBD.EXE;1
SMBD_DMPCXP_DA0 0001DA0F  [SAMBA.PRIVATE]SECRETS.TDB;1
SMBD_DMPCXP_DA0 0001DA0F  [SAMBA.VAR.LOCKS]CONNECTIONS.TDB;1
SMBD_DMPCXP_DA0 0001DA0F  [SAMBA.VAR.LOCKS]BRLOCK.TDB;1
SMBD_DMPCXP_DA0 0001DA0F  [SAMBA.VAR.LOCKS]LOCKING.TDB;1
SMBD_DMPCXP_DA0 0001DA0F  [SAMBA.VAR.LOCKS]PRINTING.TDB;1
SMBD_DMPCXP_DA0 0001DA0F  [SAMBA.VAR.LOCKS]NTDRIVERS.TDB;1
SMBD_DMPCXP_DA0 0001DA0F  [SAMBA.VAR.LOCKS]NTPRINTERS.TDB;1
SMBD_DMPCXP_DA0 0001DA0F  [SAMBA.VAR.LOCKS]NTFORMS.TDB;1
SMBD_DMPCXP_DA0 0001DA0F  [SAMBA.VAR.LOCKS]SHARE_INFO.TDB;1
SMBD_DMPCXP_DA0 0001DA0F  [SYS0.SYSMGR]SMBD_STARTUP.LOG;124
SMBD_DMPCXP_DA0 0001DA0F  [SAMBA]LOG.DMPCXP;1

Unfortunately, I didn't think to save [samba]log.dmpcxp itself.  I'm
kicking myself for that now.  That might have been interesting.

I'm thinking it might be significant that we keep our SMBD processes
around for a very long time because people didn't like having to wait
for their SMBD process to come into existence:

        deadtime = 480

Setting your deadtime as high as ours, and/or keeping a process busy
making continuous accesses over a long period of time may help reproduce
the problem.

Ben


More information about the samba-vms mailing list