Is there a port index file that corresponds to the FREEBSD_4_EOL tag?
I am unable to rebuild the index from the tagged checkout.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any
From Mikhail Teterin [EMAIL PROTECTED], Tue, Mar 21, 2006 at 06:58:01PM
-0500:
I'll try the TCP mount, workaround. If it helps, we can assume, our UDP NFS
is
broken for sustained high bandwidth writes :-(
What? I think you misunderstood. UDP NFS fairs poorly under
network congestion; it
If you feel this situation is undesirable, the first thing to do is to put
together the patches necessary to allow the kernel to actually track how
much ram+swap might be needed to cover the address-space allocations
that have been granted. This isn't trivial: just start thinking about
shared
There was some discussion about improving this situation a bit; i.e., by
permitting an option wherein sysvipc could be per jail.
Did this ever come to fruition?
Ivan: you should be aware that Kris's short disclaimer really means that
enabling the sysctl exposes sysvipc aware processes on the
A very critical question here is the network topology.
UDP NFS _cannot_ be used across switches where the ports are operating at
different speeds--unless the UDP packet size is to be smaller than MTU.
Be sure and verify that every link between the server and the client are
operating at the same
at 01:01:34AM -0800, Jon Dama wrote:
A very critical question here is the network topology.
UDP NFS _cannot_ be used across switches where the ports are operating at
different speeds--unless the UDP packet size is to be smaller than MTU.
Be sure and verify that every link between
I haven't see any evidence that suggests using NFS with UDP is actually
useful. IMO, its a false economy.
On modern hardware anyway. Keep in mind that NFS was written to run
on a 25MHz (or so) 68020.
100% agreed. That is precisely what assumed when I made my statement.
-Jon
Whatever you do, don't complain about it on this list, or you'll just be
told that if you really wanted raid, you should be running SCSI disks
Ah, no please complain so that if s/w raid gives you trouble, there will
be something to point to when and if people doubt there are still
problems
What is the output of
date vs date -u
on your system?
What's the value of machdep.adjkerntz ?
Is /etc/localtime intact?
Does anything change if you rerun tzsetup?
On Sat, 26 Nov 2005, Brett Glass wrote:
At 07:20 PM 11/25/2005, Jon Dama wrote:
Uh, the problem would be that kernel does
Uh, the problem would be that kernel does not know that the CMOS clock is
set to the local time. Standard practice is that the CMOS clock should be
set to UTC. libc then uses knowledge of the timezone to properly report
the local time.
see man adjkerntz
(adjust kernel time zone)
On Fri, 25
Yes, but only in a configuration =3GB. But I thought those problems were
ironed out? I've been looking to switch that machine back to
FreeBSD/amd64 but haven't had a chance yet. Would love to know if there
are issues ahead.
-Jon
On Thu, 8 Sep 2005, Mars G. Miro wrote:
Yo list/Soren!
Has
yes, that's quite generous.
why isn't /tmp just an mfs mount though?
On Sun, 28 Aug 2005, Colin Percival wrote:
C. Michailidis wrote:
Remember, I'm talking about the 'path of least resistance', I understand
that
I could label the slice manually with any number of different
).
Perhaps it only says that a program is not allowed to rely on /tmp being
persistent. I don't have a copy at hand :-/
-Jon
On Mon, 29 Aug 2005, Chuck Swiger wrote:
Jon Dama wrote:
yes, that's quite generous.
why isn't /tmp just an mfs mount though?
While I like that suggestion
On Tue, 30 Aug 2005, Mark Kirkwood wrote:
(FWIW - I have seen Linux + ext3 systems destroyed by power failure
because the admins refused to disable write caching on ATA drives -
Neither journelling or softupdates is much help if the HW is kidding you
about write acknowledgment).
This would
that it belongs
On Tue, 30 Aug 2005, Matthias Buelow wrote:
Jon Dama wrote:
Ironically, phk backed out the underlying support for this safety fix
from the FreeBSD kernel b.c. it wasn't integrated into the softupdates
code
whereas in reality the proper course of action would have been to hook
Where exactly did you run into trouble?
I'm guessing you made the array, you have a device for it in /dev but
ran into problems (expected) using fdisk or bsdlabel.
-Jon
On Sun, 14 Aug 2005, Brandon Fosdick wrote:
Now that my shiny new 9500S is installed and not fighting for IRQs, I've
No, it's at a level below softupdates that this must be done. Softupdates
only understands when things have been marked completed with
biodone()--the underlying scsi/ata/sata driver must make the determination
as to when biodone should be called.
The flush has to be done there. _IF_ the flush
On Fri, 15 Jul 2005, Matthias Buelow wrote:
Why am I arguing in an uphill battle here? Is data safety no longer
important to the FreeBSD community? Such issues should not even
have to be discussed at all!
I'm trying to tell you what you have to say to move forward on this issue:
1) tell
I know my drive allows disabling of the write cache, as, apparently, the
majority of IDE/SATA drives do.
Yes fair enough. This command is in the specification as far back as
ata-1. I guess it yields reasonable? performance?
You should, however, be telling sos@ this--if he doesn't already
softupdates is perfectly safe with SCSI.
its well known that ide and sata w/wo ncq fails to provide suitable
semantics for softupdates
however, journaling fairs no better, and request barriers do nothing to
solve the problem.
Request Barriers under linux exist to prevent the low level kernel
set, IF those
semantics are actually present in the hardware.
please see the thread beginning with the following commit message for an
extensive discussion of these topics:
http://lists.freebsd.org/pipermail/cvs-src/2003-April/001002.html
-Jon
On Thu, 14 Jul 2005, Matthias Buelow wrote:
Jon
imposes on other aspects of the system.
I've CCed people who hopefully know more about the actual implementation
below softupdates than I do.
-Jon
Jon Dama [EMAIL PROTECTED] writes:
if the FUA bit in the sata command header is properly respected.
if the flush cache command on an ata device
BTW,
Going from RELENG5 to RELENG6 requires an
rm -rf /usr/obj
This isn't too surprising, but its worth a note if anyone is making a
migration document.
Thanks,
Jon
On Mon, 11 Jul 2005, Scott Long wrote:
Mike Tancsa wrote:
At 05:04 PM 11/07/2005, Robert Watson wrote:
As a further
Just wondering:
How much processor migration takes place on linux mysql?
Do the threads mostly stick to the same processors?
I've noticed that on FreeBSD the 4BSD scheduler doesn't do much to
preserve cache coherency.
What sort of cache/TLB misses do you see running mysql linux vs. mysql
Try linking mysql with ptmalloc2 (instead of the system malloc obviously).
Doing this has the side-benefit of ensuring that you don't need to mess
with MAXDSIZ.
Try linking mysql with david xu's threading library.
-Jon
On Fri, 10 Jun 2005, Tom Gidden wrote:
Hi Kris,
On 10 Jun 2005, at
Yes, but surely you weren't bridging gigabit and 100Mbit before?
Did you try my suggestion about binding the IP address of the NFS server
to the 100Mbit side?
-Jon
On Tue, 31 May 2005, Skylar Thompson wrote:
Jon Dama wrote:
Try switching to TCP NFS.
a 100MBit interface cannot keep up
Yes, but surely you weren't bridging gigabit and 100Mbit before?
Did you try my suggestion about binding the IP address of the NFS server
to the 100Mbit side?
-Jon
On Tue, 31 May 2005, Skylar Thompson wrote:
Jon Dama wrote:
Try switching to TCP NFS.
a 100MBit interface cannot keep up
Oh, something else to try:
I checked through my notes and discovered that I had gotten UDP to work in
a similar configuration before. What I did was bind the IP address to
fxp0 instead of em0. By doing this, the kernel seems to send the data at
a pace suitable for the slow interface.
-Jon
Oh, something else to try:
I checked through my notes and discovered that I had gotten UDP to work in
a similar configuration before. What I did was bind the IP address to
fxp0 instead of em0. By doing this, the kernel seems to send the data at
a pace suitable for the slow interface.
-Jon
Try switching to TCP NFS.
a 100MBit interface cannot keep up with a 1GBit interface in a bridge
configuration. Therefore, in the long run, at full-bore you'd expect to
drop 9 out of every 10 ethernet frames.
MTU is 1500 therefore 1K works (it fits in one frame), 2K doesn't (your
NFS
Try switching to TCP NFS.
a 100MBit interface cannot keep up with a 1GBit interface in a bridge
configuration. Therefore, in the long run, at full-bore you'd expect to
drop 9 out of every 10 ethernet frames.
MTU is 1500 therefore 1K works (it fits in one frame), 2K doesn't (your
NFS
Could this be quantified by setting up a synthetic experiement:
1) one machine uses dummynet to generate a uniform packet/sec stream
2) another machine has a process receiving those packets and recording
their arrival relative to the local TSC. afaik, the TSC is the only
source of
, Kris Kennaway wrote:
On Wed, May 25, 2005 at 03:33:39PM -0700, Jon Dama wrote:
Could this be quantified by setting up a synthetic experiement:
1) one machine uses dummynet to generate a uniform packet/sec stream
2) another machine has a process receiving those packets and recording
It might be beneficial (pipe-dream perhaps) if the all the BSDs coalesced
around one port/packaging system. I hear that netbsd's port system has
the metadata necessary to support different OSs and different OS versions
within one coherent system.
What do you think about the relative strengths of
34 matches
Mail list logo
