-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Claus Guttesen wrote:
>> I have read all related threads about performance problems with multi
>> core systems but still have no idea what to do to make thinks better.
>> Below are results of testing postgresql on HP DL380G5 using sysbench.
>> The resu
Miroslav Lachman wrote:
> Oliver Fromme wrote:
> > if [ -z "$SHELL" -o ! -x "$jail_path/$SHELL" ]; then
> > login_shell="$SHELL"
> > else
> > login_shell="/bin/sh"
> > fi
Ian Smith brought to my attention that I got the logic
reversed in the if statement.
Brian <[EMAIL PROTECTED]> wrote:
> Joshua Coombs wrote:
> > For a very short while with 6.0 I was tweaking the kernel to detect
> > 386s as 486s, as well as using CPU_DISABLE_CMPXCHG and having ok
> > luck. I've now got a Cyrix 486DrX-2 66 installed in place of my
> > Am386DX-40, which sup
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Krassimir Slavchev wrote:
> Hello,
>
> I have read all related threads about performance problems with multi
> core systems but still have no idea what to do to make thinks better.
> Below are results of testing postgresql on HP DL380G5 using sysbench
was just experimenting with zfs on a spare slice on the disc - this may all
be entirely my fault for doing it worng, if so please tell me, but I
appear to be gettign a zfs pool ounted on reboot but with none of the
data appearing in it!
what I did:
1) take a space slice, only got one partition on
I would like to request your opinion on the following proposal:
1. introduce new scsi_sense_action_qualifier value
SSQ_PRINT_SENSE_VERBOSE, which would mean that detailed command and
response information is to be printed only if bootverbose==1;
2. introduce new define SS_FATAL_NORMAL with value
heh I had the same prob a couple days back. Check the archives last
week, 10DEC07 "Re: Various Issues with 7.0-BETA4"
Step by step directions on how to fix
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-sta
> heh I had the same prob a couple days back. Check the archives last
> week, 10DEC07 "Re: Various Issues with 7.0-BETA4"
actually, it wsa that thread which motivated me to experiment ... and
I was thinking all along "must remember to add zfs to loader.conf to
avoid that". Of course I then forgot
O.K., even odder - it seems that something is creating a real '/tank'
directory in '/' for some reaosn, but not mounting the filesystems onto
it. when I reboot I get this:
# zpool status
pool: tank
state: ONLINE
scrub: none requested
config:
Are you sure that the settitle call is disabled on FreeBSD?
On 12/20/07, Krassimir Slavchev <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello,
>
> I have read all related threads about performance problems with multi
> core systems but still have no idea what
* David G Lawrence <[EMAIL PROTECTED]> [071219 09:12] wrote:
> > >Try it with "find / -type f >/dev/null" to duplicate the problem
> > >almost
> > >instantly.
> >
> > I was able to verify last night that (cd /; tar -cpf -) > all.tar would
> > trigger the problem. I'm working getting a test runn
> >Unfortunately, the version of the patch that I sent out isn't going to
> > help your problem. It needs to yield at the top of the loop, but vp isn't
> > necessarily valid after the wakeup from the msleep. That's a problem that
> > I'm having trouble figuring out a solution to - the solutions
* David G Lawrence <[EMAIL PROTECTED]> [071221 15:42] wrote:
> > >Unfortunately, the version of the patch that I sent out isn't going to
> > > help your problem. It needs to yield at the top of the loop, but vp isn't
> > > necessarily valid after the wakeup from the msleep. That's a problem tha
I'm just an observer, and I may be confused, but it seems to me that this is
motion in the wrong direction (at least, it's not going to fix the actual
problem). As I understand the problem, once you reach a certain point, the
system slows down *every* 30.999 seconds. Now, it's possible for the co
The uio_yield() idea did not work. Still have the same 31 second
interval
packet loss.
Is it safe to assume the vp will be valid after a msleep() or
uio_yield()? If
so can we do something a little different:
Currently:
/* this takes too long when list is large */
MNT_VNODE_FOREACH(vp, mp
On Fri, Dec 21, 2007 at 05:43:09PM -0800, David Schwartz wrote:
>
>
> I'm just an observer, and I may be confused, but it seems to me that this is
> motion in the wrong direction (at least, it's not going to fix the actual
> problem). As I understand the problem, once you reach a certain point, t
Another attempt to use USB-storage with FreeBSD, another moment of
hair-pulling frustration.
I attach the card-reader with the media card already inserted (detection of
card-insertion has not worked in a long time, if ever).
The "disk" appears:
umass1: Genesys USB Reader, rev 2.00/91.3
On Fri, Dec 21, 2007 at 10:30:51PM -0500, Mark Fullmer wrote:
> The uio_yield() idea did not work. Still have the same 31 second
> interval packet loss.
What patch you have used ?
Lets check whether the syncer is the culprit for you.
Please, change the value of the syncdelay at the sys/kern/vfs
On Fri, Dec 21, 2007 at 04:24:32PM -0800, Alfred Perlstein wrote:
> * David G Lawrence <[EMAIL PROTECTED]> [071221 15:42] wrote:
> > > >Unfortunately, the version of the patch that I sent out isn't going
> > > > to
> > > > help your problem. It needs to yield at the top of the loop, but vp
>
I will need to build several Web caches over the next few months,
and just took advantage of the Christmas lull (and a snowy day,
when I couldn't work outside) to test FreeBSD 7.0 BETA 4 to see how
it will perform at this task. I built up a 4 core FreeBSD box, and
asked a friend who's a Linux f
On Dec 22, 2007, at 12:36 AM, Kostik Belousov wrote:
On Fri, Dec 21, 2007 at 10:30:51PM -0500, Mark Fullmer wrote:
The uio_yield() idea did not work. Still have the same 31 second
interval packet loss.
What patch you have used ?
This is hand applied from the diff you sent December 19, 2007
> >What patch you have used ?
>
> This is hand applied from the diff you sent December 19, 2007 1:24:48
> PM EST
Mark, try the previos patch from Kostik - the one that does the one
tick msleep. I think you'll find that that one does work. The likely
problem with the second version is that ui
On Sat, Dec 22, 2007 at 01:28:31AM -0500, Mark Fullmer wrote:
>
> On Dec 22, 2007, at 12:36 AM, Kostik Belousov wrote:
> >Lets check whether the syncer is the culprit for you.
> >Please, change the value of the syncdelay at the sys/kern/vfs_subr.c
> >around the line 238 from 30 to some other value
> I'm just an observer, and I may be confused, but it seems to me that this is
> motion in the wrong direction (at least, it's not going to fix the actual
> problem). As I understand the problem, once you reach a certain point, the
> system slows down *every* 30.999 seconds. Now, it's possible for
> As Bruce Evans noted, there is a vfs_msync() that do almost the same
> traversal of the vnodes. It was missed in the previous patch. Try this one.
I forgot to comment on that when Bruce pointed that out. My solution
has been to comment out the call to vfs_msync. :-) It comes into play
when yo
> > > Can you use a placeholder vnode as a place to restart the scan?
> > > you might have to mark it special so that other threads/things
> > > (getnewvnode()?) don't molest it, but it can provide for a convenient
> > > restart point.
> >
> >That was one of the solutions that I considered and
26 matches
Mail list logo
