>
> :>-vfs.nfs.realign_test: 22141777
> :>+vfs.nfs.realign_test: 498351
> :>
> :>-vfs.nfsrv.realign_test: 5005908
> :>+vfs.nfsrv.realign_test: 0
> :>
> :>+vfs.nfsrv.commit_miss: 0
> :>+vfs.nfsrv.commit_blks: 0
> :>
> :> changing them did nothing - or at least with respec
:how can I see the IP fragment reassembly statistics?
:
:thanks,
: danny
netstat -s
Also look for unexpected dropped packets, dropped fragments, and
errors during the test and such, they are counted in the statistics
as well.
-Matt
On 2008-Sep-26 23:44:17 -0700, Jeremy Chadwick <[EMAIL PROTECTED]> wrote:
>On Fri, Sep 26, 2008 at 10:35:57PM -0700, Derek Kuli??ski wrote:
>> As far as I know (at least ideally, when write caching is disabled)
...
>FreeBSD atacontrol does not let you toggle such features (although "cap"
>will show
Hello Jeremy,
Friday, September 26, 2008, 11:44:17 PM, you wrote:
>> As far as I know (at least ideally, when write caching is disabled)
> Re: write caching: wheelies and burn-outs in empty parking lots
> detected.
> Let's be realistic. We're talking about ATA and SATA hard disks, hooked
> up
On Fri, Sep 26, 2008 at 11:44:17PM -0700, Jeremy Chadwick wrote:
> On Fri, Sep 26, 2008 at 10:35:57PM -0700, Derek Kuli??ski wrote:
> > Hello Jeremy,
> >
> > Friday, September 26, 2008, 10:14:13 PM, you wrote:
> >
> > >> Actually what's the advantage of having fsck run in background if it
> > >>
> > IMHO, a dirty filesystem should not be mounted until it's been fully
> > analysed/scanned by fsck. So again, people are putting faith into
> > UFS2+SU despite actual evidence proving that it doesn't handle all
> > scenarios.
>
> Yes, I think the background fsck should be disabled by default,
> --==_Exmh_1222467420_5817P
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> David,
>
> You beat me to it.
>
> Danny, read the iperf man page:
>-b, --bandwidth n[KM]
> set target bandwidth to n bits/sec (default 1 Mbit/sec). This
>
On 27/09/2008, at 1:02 PM, Jeremy Chadwick wrote:
Anyway, I'd like to know why you have so many fds open
simultaneously in
the first place. We're talking over 11,000 fds actively open at
once --
this is not a small number. What exactly is this machine doing? Are
you absolutely certain tu
Jeremy Chadwick <[EMAIL PROTECTED]> writes:
> On Fri, Sep 26, 2008 at 06:21:01PM +0200, Christian Laursen wrote:
>> I decided to give 7.1-PRERELEASE a try on one of my machines to find
>> out if there might be any problems I should be aware of.
>>
>> I quickly ran into problems. After a while the
On Sat, 27 Sep 2008, Christian Laursen wrote:
I am now back to running with everything I usually have running on this
machine (my primary desktop) but without the ipfw uid rules and the machine
is rock stable.
I have been running with debug.mpsafenet="0" most likely because I have been
usin
On Fri, 26 Sep 2008, Danny Braniss wrote:
after more testing, it seems it's related to changes made between Aug 4 and
Aug 29 ie, a kernel built on Aug 4 works fine, Aug 29 is slow. I'l now try
and close the gap.
I think this is the best way forward -- skimming August changes, there are a
num
On Sat, Sep 27, 2008 at 12:37:50AM -0700, Derek Kuli??ski wrote:
> Friday, September 26, 2008, 11:44:17 PM, you wrote:
>
> >> As far as I know (at least ideally, when write caching is disabled)
>
> > Re: write caching: wheelies and burn-outs in empty parking lots
> > detected.
>
> > Let's be rea
> On Fri, 26 Sep 2008, Danny Braniss wrote:
>
> > after more testing, it seems it's related to changes made between Aug 4 and
> > Aug 29 ie, a kernel built on Aug 4 works fine, Aug 29 is slow. I'l now try
> > and close the gap.
>
> I think this is the best way forward -- skimming August changes
[EMAIL PROTECTED] wrote:
> [...]
> > > IMHO, a dirty filesystem should not be mounted until it's been fully
> > > analysed/scanned by fsck. So again, people are putting faith into
> > > UFS2+SU despite actual evidence proving that it doesn't handle all
> > > scenarios.
> >
> > Yes, I think
Jeremy Chadwick wrote:
> I believe we're in overall agreement with regards to background_fsck
> (should be disabled by default).
In fact background fsck has been introduced for a good reason:
waiting for a full fsck on modern big disks is far too long.
Similarly write cache is enabled on ata disk
I'm running 7.1-PRERELEASE, with /usr/src and /usr/ports last csup-ed
just a few days ago. After being up for about a day or so the system
will panic because of a page fault. I'm not completely sure, but it
seems that the system is more stable when gdm and gnome are disabled in
rc.conf. At l
Danny Braniss wrote:
I know, but I get about 1mgb, which seems somewhat low :-(
If you don't tell iperf how much bandwidth to use for a UDP test, it
defaults to 1Mbps.
See -b option.
http://dast.nlanr.net/projects/Iperf/iperfdocs_1.7.0.php#bandwidth
--eli
--
Eli Dart
ES
I'm forking the thread on fsck/soft-updates in hopes of getting some
practical advice based on the discussion here of background fsck,
softupdates and write-caching on SATA drives.
On Fri, 26 Sep 2008, Jeremy Chadwick wrote:
Let's be realistic. We're talking about ATA and SATA hard disks, ho
Jeremy Chadwick wrote:
On Sat, Sep 27, 2008 at 11:10:01AM +1000, Aristedes Maniatis wrote:
By default FreeBSD 7.0 shipped with the sysctls set to:
kern.maxfiles: 12328
kern.maxfilesperproc: 11095
[...]
Anyway, I'd like to know why you have so many fds open simultaneously in
the first place
On Sat, Sep 27, 2008 at 03:16:11PM -0400, Charles Sprickman wrote:
> On Fri, 26 Sep 2008, Jeremy Chadwick wrote:
>> Let's be realistic. We're talking about ATA and SATA hard disks, hooked
>> up to on-board controllers -- these are the majority of users. Those
>> with ATA/SATA RAID controllers (no
On Sat, Sep 27, 2008 at 10:14:09PM +0200, Miroslav Lachman wrote:
> Jeremy Chadwick wrote:
>> On Sat, Sep 27, 2008 at 11:10:01AM +1000, Aristedes Maniatis wrote:
>>
>>> By default FreeBSD 7.0 shipped with the sysctls set to:
>>>
>>> kern.maxfiles: 12328
>>> kern.maxfilesperproc: 11095
>
> [...]
>
>
Miroslav Lachman wrote:
> I don't know what files are "really" open in the meaning of
> kern.maxfiles. I have webserver with about 100 hosted domains and there
> is some numbers:
>
> [EMAIL PROTECTED] ~/# fstat -u www | wc -l
> 9931
> [EMAIL PROTECTED] ~/# fstat -u root | wc -l
>
On 2008-Sep-27 22:14:09 +0200, Miroslav Lachman <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] ~/# fstat -u www | wc -l
> 9931
>[EMAIL PROTECTED] ~/# fstat -u root | wc -l
> 718
>[EMAIL PROTECTED] ~/# fstat | grep httpd | wc -l
> 6379
>[EMAIL PROTECTED] ~/# fstat | grep httpd | wc -l
>
An FYI: In the past couple of days, presumably as testing of 7.x becomes more
widespread, I've seen several reports of instability resulting from ipfw
credential rules. For those unfamiliar with them, these allow the matching of
packets in ipfw rules based on the credentials of the socket tha
Hello,
I've serious network performance problems on a HP Turion X2
based brand new notebook; I only used a 7-1Beta CD and
7-STABLE on this thing.
Scp-ing ports.tgz from a rock-stable 7-STABLE server to it gives :
# scp -p ports.tgz [EMAIL PROTECTED]:/tmp/
ports.tgz
On Sat, Sep 27, 2008 at 07:05:08PM +1000, Aristedes Maniatis wrote:
>
> On 27/09/2008, at 1:02 PM, Jeremy Chadwick wrote:
>
> >Anyway, I'd like to know why you have so many fds open
> >simultaneously in
> >the first place. We're talking over 11,000 fds actively open at
> >once --
> >this is
On 28/09/2008, at 8:18 AM, Gary Palmer wrote:
At least one port recommends you set
kern.maxfiles="4"
in /boot/loader.conf. I think its one of the GNOME ports. I'm pretty
confident you can run that without too many problems, and maybe go
higher,
but if you really want to know the limit
Peter Jeremy wrote:
On 2008-Sep-27 22:14:09 +0200, Miroslav Lachman <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] ~/# fstat -u www | wc -l
9931
[EMAIL PROTECTED] ~/# fstat -u root | wc -l
718
[EMAIL PROTECTED] ~/# fstat | grep httpd | wc -l
6379
[EMAIL PROTECTED] ~/# fstat | grep httpd
I have made an update for the top(1) utility in the FreeBSD base
system to get it from the 3.5b12 version to the 3.8b1 version.
I have tried them on the amd64 architecture on FreeBSD -current and
FreeBSD 7.0 and on the i386 architecture on FreeBSD 7.0.
The big new features are a line upper part w
29 matches
Mail list logo
