Date: Sun, 22 Oct 2000 15:08:46 -0400 From: "John W. De Boskey" <jwd@FreeBSD.org> To: Mark Huizer <freebsd@dohd.org> Cc: "Jordan K. Hubbard" <jkh@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/etc rc Message-ID: <20001022150846.A37208@bsdwins.com> In-Reply-To: <20001022202817.A30674@dohd.cx>; from freebsd@dohd.org on Sun, Oct 22, 2000 at 08:28:17PM %2B0200 References: <freebsd@dohd.org> <82968.972178582@winston.osd.bsdi.com> <20001022202817.A30674@dohd.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Mark Huizer's Original Message ----- > > > Hmm... that putting the entropy reseeding in background doesn't improve > > > anything if 2 lines later ldconfig, mfs, or whatever sets in and blocks > > > for it? > > Yeah, I should have noted that I wasn't considering this a major > > speed-up so much as a simple stylistic point. The amount of actual > > time gained would be relatively fractional unless that dd is stuffing > > far more data down /dev/random than is needed for sshd or whatever. The 1st dd is transferring about 28k. The 2nd dd is transferring about 570k. My belief is the 2nd seeding is way too large. For instance, it is transferring all of the termcap database to /dev/random, but there is basically no random data in there, it's all static, to the tune of about 180k. I'd actually like to get rid of the 2nd dd, and improve upon the first by going after such things as 'mount -v' and the master.passwd file. Just a point, the reason I left the stderr from dd available was so that folks wouldn't have to guess about what's being done. After we determine the best course of action, then the output relating to the amount of data fed to /dev/random can be tossed to devnull (this is in jordan's court since he committed the devnull redirect). > Either you have data to give to /dev/random, not needing all entropy > gathering, giving you no gain by backgrounding it. Or you don't have the > data and you need entropy and you don't have enough for most of the > processes coming later. I still see no gain, not even stylistic :-) I tend to agree. Where we have a few interesting problems are processes which are going after randomness before /dev/random has been seeded (ie: mfs). In looking at the mfs code, I don't really understand yet why an mfs requires randomness to set it up. Comments welcome. -John > Mark > -- > Nice testing in little China... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001022150846.A37208>