Date: Fri, 1 Jul 2005 00:37:43 +0200 From: Max Laier <max@love2party.net> To: freebsd-stable@freebsd.org Cc: Matt Juszczak <matt@atopia.net>, Maciej Wierzbicki <voovoos-stable@killfile.pl> Subject: Re: Two Options: which to choose? Message-ID: <200507010037.51304.max@love2party.net> In-Reply-To: <20050630215801.GA29000@mail.media4u.pl> References: <20050630164529.D65760@neptune.atopia.net> <20050630175234.J67125@neptune.atopia.net> <20050630215801.GA29000@mail.media4u.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart2948519.URzfZD7qbs Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 30 June 2005 23:58, Maciej Wierzbicki wrote: > On Thu, Jun 30, 2005 at 05:53:20PM -0400, Matt Juszczak wrote: > > You say it didn't crash for a month, but then you say to try FreeBSD wi= th > > PF because it works perfectly. To me, a month of uptime isn't perfectl= y. > > It is, comparing to two- or three-day uptime periodic when it crashes. Wi= th > IPF. :-) > > > Can you elaborate? Is your machine still crashing even though its taki= ng > > a month instead of a few days like it did previously? > > What I meant was: after removing IPF I did not get any crash. I have said it before, I'll say it again for the record: IPF's shared lock= =20 implementation is *BROKEN* by design. This is caused by a misunderstanding= =20 of the sx(9) implementation in FreeBSD - it seems to me. The problem with= =20 the current sx(9) implementation is that it *sleeps* (not to confuse with=20 "blocks") in the shared case which leads to deadlocks/panics/and other bad= =20 things. The only way out of this at the moment is a hand-rolled shared loc= k=20 implementation (as done for pfil(9) and ipfw) which has to take care of=20 starvation protection somehow. The existing sx(9) ignores this issue by=20 sleeping in the shared case, which is valid in some cases but just not=20 practical here. One might argue that this is hardly IPF's fault and sx(9) should be fixed. = =20 The way in which the reworked locking was rushed into RELENG_5, however, wa= s=20 far from professional (IMHO) and is what causes you the headache.</rant> I hope that PF does it better when we change to a shared lock - which I am= =20 certainly planing on. This is a non-trivial task and needs time. Right no= w=20 there is one issue with PF and SMP which is documented in the pf.conf(5)=20 manpage. In 5.4 there is an additional problem with pfsync that has been=20 fixed in RELENG_5 a couple of days ago. To summarize: Unless you see crashes unrelated to PF or network, you should= =20 stay with 5.4+PF as it is in good shape. If you see crashes that hint into= =20 the PF/network corner, please let us know. Most of the time "debug.mpsafen= et=20 =3D 0" can help to fix things, it's up to you if the performance implicatio= n is=20 a problem. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2948519.URzfZD7qbs Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCxHQ/XyyEoT62BG0RAv0BAJ93Dqr3Eg613XDvhlcgB48/CM2X6wCePyXG 8e1EkHeYF3L2WQPxJbfjylg= =nWNk -----END PGP SIGNATURE----- --nextPart2948519.URzfZD7qbs--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200507010037.51304.max>