Thus spake Nate Williams ([EMAIL PROTECTED]):
Or even more paranoid and slightly shorter. ;)
find /local2/CVSfoo -name Root -print | fgrep CVS |
perl -pi -e 's#/local#/local2/#g;'
Hehe, yes ;-)
But, as bp mentioned already in IRC:
find
In message [EMAIL PROTECTED] Alexander Langer writes:
: Thus spake Nate Williams ([EMAIL PROTECTED]):
: Or even more paranoid and slightly shorter. ;)
: find /local2/CVSfoo -name Root -print | fgrep CVS |
: perl -pi -e 's#/local#/local2/#g;'
Yes, but older Repository files must also be
Christopher Sedore wrote:
On Thu, 6 Jan 2000, Arjan de Vet wrote:
Jordan K. Hubbard wrote:
This is very interesting data and I was just wondering about the
actual state of functionality in our AIO code just the other day,
oddly enough. Does anyone have a PR# for the mentioned patches?
Wes Peters wrote:
Matthew Jacob wrote:
Mike Smith has been interested in getting FreeBSD involved in this. My
attitude has been "Over my dead body" (you have to watch out saying
things like that- someone might respond with, "Uh, okay")
Uh, okay. Anything to help Mike out.
On Mon, Jan 10, 2000 at 10:48:29PM +0100, Arjan de Vet wrote:
Christopher Sedore wrote:
On Thu, 6 Jan 2000, Arjan de Vet wrote:
Jordan K. Hubbard wrote:
This is very interesting data and I was just wondering about the
actual state of functionality in our AIO code just the other
convince us that we should abandon our _very_ thin driver architecture
for one that's at least an order of magnitude more complex.
Thin is not necessarily bad as it leaves a lot of room to maneuver.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the
:Recently I was tasked to find a way to scale up our MYSQL server, running
:MYSQL3.22.15 on FreeBSD3.3. I've been testing a hardware RAID solution,
:and found that with 6 disks in a RAID5 configuration, the system was only
:perhaps 30% faster than when running on a single disk. [The 6 disks in
Recently I was tasked to find a way to scale up our MYSQL server, running
MYSQL3.22.15 on FreeBSD3.3. I've been testing a hardware RAID solution,
and found that with 6 disks in a RAID5 configuration, the system was only
perhaps 30% faster than when running on a single disk. [The 6 disks in
:find
: linuxthreads to meet your needs at the moment.
:
:That's being tested in parallel. The main issue with LinuxThreads is that
:we'd go from running ~25 processes on this server to running ~800.
Yes, but they are rfork(RF_MEM)'d processes - they share a lot of
context between
On Mon, 10 Jan 2000, Scott Hess wrote:
4) Is there anyone willing to commit to testing my modified pthreads
library against MYSQL? [I'll be stress testing it quite heavily, of
course. It would probably also be testable against Squid with async I/O
and multithreaded Apache 2.0.]
I'm
"Scott" == Scott Hess [EMAIL PROTECTED] writes:
Scott Recently I was tasked to find a way to scale up our MYSQL server, running
Scott MYSQL3.22.15 on FreeBSD3.3. I've been testing a hardware RAID solution,
Scott and found that with 6 disks in a RAID5 configuration, the system was only
Scott
Patryk Zadarnowski [EMAIL PROTECTED] wrote:
I'm no expert on pthreads, but, if you decide to proceed with
implementing a mixed user-land/rfork pthread implementation, may I
suggest that you implement is through POSIX pthread_attr_setscope()
interfaces instead of some local extension.
"f.johan.beisser" wrote:
On Mon, 10 Jan 2000, Alex wrote:
Wes Peters wrote:
Matthew Jacob wrote:
Mike Smith has been interested in getting FreeBSD involved in this. My
attitude has been "Over my dead body" (you have to watch out saying
things like that- someone
On Mon, 10 Jan 2000 [EMAIL PROTECTED] wrote:
[...]
1) Does this seem like a reasonable approach? [It _works_, and well. But
it tastes strongly of hack.]
I'm not very fond of this approach to the problem, though it can work, as
you note. Asynchronous I/O is in my opinion a much
Hi all,
I was tinkering with mergemaster tonight adding in something that seems useful
to me. I track -stable and have found mergemaster very valuable--however,
sometimes choosing 'd' over and over again for things I don't want touched
(like root's .profile or .cshrc or /etc/networks, etc.) can
On Mon, 10 Jan 2000, Alfred Perlstein wrote:
:I've implemented a rough fix, which is to rfork() processes which I label
[snip]
The linuxthreads port is at least four times faster and, since it uses
rfork(), will be I/O optimal. However, since only FreeBSD-4.x implements
16 matches
Mail list logo
