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