Our more serious issue: two kinds of Samba read corruption
BG - Ben Armstrong
BArmstrong at dymaxion.ca
Tue Sep 28 16:47:48 GMT 2004
On Mon, 2004-09-27 at 23:25 -0400, John E. Malmberg wrote:
> BG - Ben Armstrong wrote:
> >
> > - show process/acc on the user's smbd process
>
> show proc/acc/quota may provide mroe information.
I'll keep that in mind.
> > Accounting information:
> > Buffered I/O count: 193317 Peak working set size: 14640
> > Direct I/O count: 44366 Peak virtual size: 184880
>
> What is the physical memory + pgflquo for the process? Is it equal or
> close to 184880?
The SMBD processes are apparently owned by SYSTEM. That account is
configured like this:
UAF> sho system
Username: SYSTEM Owner: SYSTEM MANAGER
[snip]
Maxjobs: 0 Fillm: 300 Bytlm: 65536
Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0
Maxdetach: 0 BIOlm: 128 JTquota: 4096
Prclm: 20 DIOlm: 384 WSdef: 256
Prio: 4 ASTlm: 410 WSquo: 16384
Queprio: 0 TQElm: 100 WSextent: 20000
CPU: (none) Enqlm: 2048 Pgflquo: 200000
But I have also reproduced the problem on a test system which has a much
higher Pgflquo (500000) for SYSTEM:
Maxjobs: 0 Fillm: 100 Bytlm: 64000
Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0
Maxdetach: 0 BIOlm: 150 JTquota: 4096
Prclm: 20 DIOlm: 150 WSdef: 2000
Prio: 4 ASTlm: 250 WSquo: 4000
Queprio: 0 TQElm: 100 WSextent: 16384
CPU: (none) Enqlm: 2048 Pgflquo: 500000
I am providing JYC with a large zipped backup saveset of a directory
full of files that reproduces the problem.
> > 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
>
> Is if possible that the process ran out of virtual memory? If so, then
> the next step is to try to determine where the memory leak is.
I don't think so. I don't see memory usage growing. I'm hoping that
the with the saveset I have provided JYC, he'll be able to finally track
this one down.
Ben
More information about the samba-vms
mailing list