Date: Mon, 17 Sep 2001 22:54:03 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Rik van Riel <riel@conectiva.com.br> Cc: Christoph Hellwig <hch@ns.caldera.de>, Dennis Berger <Dennis.Berger@nipsi.de>, freebsd-fs@FreeBSD.ORG, opengfs-devel@lists.sourceforge.net Subject: Re: Porting a new filesystem to FreeBSD Message-ID: <3BA6E17B.7DD12261@mindspring.com> References: <Pine.LNX.4.33L.0109170929540.2990-100000@imladris.rielhome.conectiva>
next in thread | previous in thread | raw e-mail | index | archive | help
Rik van Riel wrote: > > The problem is that you have proposed a technical solution which > > is politically impossible. You have to expect political reasons > > why it is impossible to result from the suggestion. > > Interesting that you have to be offended by this, since > you seem to keep your "1 million tcp connections" stuff > proprietary ;) I posted the patch for the FreeBSD ucred stuff to the FreeBSD lists; it was incorporated in FreeBSD proper. I also posted the patches to allow tuning of open files and TCP vs. UDP sockets seperately, at boot time, but they were rejected, though no one else came up with a better way of achieving the same goal. The client side is somewhat a different matter. I posted the hash collision domain fixes for outbound connections to -current, as well. While it's unreasonable to do a million connections from a client, FreeBSD still has a number of bugs that mean you have to be very, very careful about how you code your client program to be able to do that level of connections. Effectively, you have to explicitly trigger the three "if" statements that get you around sharing the collision domain, even after the patches. No one has really bothered to look at the TCP code, or the problem would be obvious to them, the fix less so: I haven't bothered to fix it because I don't need that many client connections for my (mostly) server product. If anyone really cared, they'd bring in my patch, and then tackle the hash algorithm used to select ports, as well as the port reuse case when a port is in the "ALL" vs. "one or more single interfaces" hash collision case. The rest is a matter of tuning, and I have jumped down the throats of people who can't tune a system to save their lives (including those stupid benchmarks on the SPAM engine that showed FreeBSD to be "so poor"), that I can't count the number on both hands and both feet. People who think they can sysctl FreeBSD into a high performance box are deluded. > If that means you won't be able to use opengfs or xfs in > your product, that's bad luck for you. But please don't > try to persuade people to not port something which could > be useful for many other freebsd users... I am one of a handful of people capable of doing the work in a reasonably short period of time. I am merely stating my opinion on the utility of the work, to me. The other people I know who are in the same boat (at Zambeel and elsewhere) are also embedded systems people. If you can recruit some user space perl script kiddie to do the work for you, then don't let me dissuade them from doing the work, or from you accepting their code into your source repository. If on the other hand, you want the work done by someone with 20 years of UNIX kernel experience and over 10 puttering around in UNIX file systems, then you will need to come up with a more compelling argument than "other people can use it, but you can't -- please do the work anyway". Cheers, -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BA6E17B.7DD12261>