9-STABLE, ZFS, NFS, ggatec - suspected memory leak

[Hiroki Sato]

Rick Macklem <rmacklem at uoguelph.ca> wrote
  in <1527622626.3418715.1335445225510.JavaMail.root at erie.cs.uoguelph.ca>:

rm> Steven Hartland wrote:
rm> > ---- Original Message -----
rm> > From: "Rick Macklem" <rmacklem at uoguelph.ca>
rm> > > At a glance, it looks to me like 8.x is affected. Note that the
rm> > > bug only affects the new NFS server (the experimental one for 8.x)
rm> > > when exporting ZFS volumes. (UFS exported volumes don't leak)
rm> > >
rm> > > If you are running a server that might be affected, just:
rm> > > # vmstat -z | fgrep -i namei
rm> > > on the server and see if the 3rd number shown is increasing.
rm> >
rm> > Many thanks Rick wasnt aware we had anything experimental enabled
rm> > but I think that would be a yes looking at these number:-
rm> >
rm> > vmstat -z | fgrep -i namei
rm> > NAMEI: 1024, 0, 1, 1483, 25285086096, 0
rm> > vmstat -z | fgrep -i namei
rm> > NAMEI: 1024, 0, 0, 1484, 25285945725, 0
rm> >
rm>                   ^
rm> I don't think so, since the 3rd number (USED) is 0 here.
rm> If that # is increasing over time, you have the leak. You are
rm> probably running the old (default in 8.x) NFS server.

 Just a report, I confirmed it affected 8.x servers running newnfs.

 Actually I have been suffered from memory starvation symptom on that
 server (24GB RAM) for a long time and watching vmstat -z
 periodically.  It stopped working once a week.  I investigated the
 vmstat log again and found the amount of NAMEI leak was 11,543,956
 (about 11GB!) just before the locked-up.  After applying the patch,
 the leak disappeared.  Thank you for fixing it!

-- Hiroki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20120427/5d404841/attachment.pgp