Date: Sun, 3 Feb 2008 11:36:49 -0500 From: Louis Mamakos <louie@transsys.com> To: Alexander Motin <mav@freebsd.org> Cc: cvs-src@FreeBSD.org, Gleb Smirnoff <glebius@FreeBSD.org>, cvs-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/netgraph/netflow ng_netflow.c Message-ID: <C0C34BEB-3EB8-4552-B0BD-CE481311C77A@transsys.com> In-Reply-To: <47A4E122.8080901@FreeBSD.org> References: <200801271501.m0RF1Hki089075@repoman.freebsd.org> <20080202201153.GL14339@FreeBSD.org> <47A4E122.8080901@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 2, 2008, at 4:31 PM, Alexander Motin wrote: > Gleb Smirnoff =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> you should have asked me for review before committing! This is >> not a bug, this is a feature. This was quite clear from the comments, >> that you removed: >> - /* if export hook disconnected stop running expire(). */ >> This is intended behavior. We must not lose information unless >> user explicitly wants to lose information. In the latter case >> he will connect ng_hole(4) node to the "export" hook. But we must >> not lose information if user runs some script that swaps receiving >> node on the "export" hook. >> Please backout this change! > > Expire process was not depending completely on connected hook even =20 > before this commit. For example, every TCP session closing forces =20 > some data export. So even with export hook disconnected some data =20 > still will be lost and not just lost, but it was leading to memory =20 > leak which I have fixed with other commit. > > So if you insist that it was a feature then sorry. Then it should be =20= > documented and fixed to work correctly. But as soon as nobody notice =20= > that memory leak, probably nobody uses this feature actively. > > --=20 > Alexander Motin > If there's a concern about no losing the netflow data, then it's =20 likely that it's usually the case that an export hook is connected. =20 If a user wanted to change the export arrangement for the netflow =20 data, then just disconnected and reconnecting to the export hook won't =20= caused data to be lost if the expiry parameters are set to something =20 reasonable. Finally, in the absence of infinite amounts of memory, data will =20 eventually be lost. The only decision is over what duration data =20 should be kept around so that it might be harvested. It's a huge =20 surprise that the netflow module consumes large amounts of kernel =20 memory. As a user, I expected the expiration timers to be the policy =20= that I specify to control how long the netflow stats are stored, and =20 my expectation wasn't met. Louis Mamakos
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C0C34BEB-3EB8-4552-B0BD-CE481311C77A>