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
isn't capable of fixing things?
Isn't it more dangerous to be it like that? i.e.
:-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 respect to nfs throughput
: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 you if
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 to
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
isn't capable of
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, with a
--==_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
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 system
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
using
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
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 realistic.
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
[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 the background
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 disks
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
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
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,
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
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 (not
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
[...]
Anyway, I'd like to
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
718
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
6002
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
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 not a small
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
29 matches
Mail list logo
