gmirror on 7B4
Hello, I seem to remember a similar question being asked in the past. But never really saw a definitive answer to it. So let's try it again. :) I'm looking to upgrade all our servers to 7 in the not-to-distant future. As I look to overcome the quirks in 7 as they apply to our hardware (I'm already testing it on one of our not-so prominent servers). We have a mail server with an Adaptec SCSI chip with 2 ULTRA-160 ports. The primary port runs the booted 6.2 on the only HD on that port. The other devices on that chain are accessories, such as tape, etc... The other port has 3 HD's on it, all of which are of equal size and model. Which go unused. I had originally intended to create a raid mirror on the whole lot of HD's during the install process. But I wasn't presented, nor could I find that option during install. So, due to lack of time, pushed it off till later, and simply installed onto the one HD. Now to my question(s)... Where is the option to create, and install to a gMIRRORED drive-set? If not, why? If not, it possible to install to one drive, mirror all available drives with the data on the installed drive? Please note, 1) I have examined the gmirror (and related mirror) info I could find. But given that much of this is a rapidly evolving area in FBSD (in 7 especially) I thought it was worth asking here. 2) In my cases above, I'm interested in RAID-0 (mirroring for /volume/ not redundancy). Thank you very much for all your time and consideration. Chris -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
devfs.rules include rule question in 6.2 release
Hi, It seems you can't recursively use the include rule specification with devfs in Freebsd 6.2. I couldn't see a note about this in the devfs man page so I'm not sure whether this is expected behaviour or not. For example, the devfsrules_jail is defined as the following in /etc/defaults/devfs.rules [devfsrules_jail=4] add include $devfsrules_hide_all add include $devfsrules_unhide_basic add include $devfsrules_unhide_login When I create a custom rule in /etc/devfs.rules such as the following: [devfsrules_unhide_bpf=10] add path 'bpf*' unhide [devfsrules_dhcp=11] add include $devfsrules_jail add include $devfsrules_unhide_bpf All devices are actually enabled in my jail without any errors. However, if I change my devfsrules_dhcp so that I don't have any sub includes everything works OK: [devfsrules_dhcp=11] add include $devfsrules_hide_all add include $devfsrules_unhide_basic add include $devfsrules_unhide_login add include $devfsrules_unhide_bpf Obviously the first version is preferable as I don't need to know about the inner workings of devfsrules_jail - particularly during upgrades. Is that the expected behaviour? Kind regards, Geoff ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
aac tool regressions on 7.0-RC1
I'm seeing some regressions in the various management tools for Adaptec AAC cards on FreeBSD 7.0-RC1 amd64. I'm trying to use both the 32-bit FreeBSD aaccli binary from the sysutils/aaccli port, and also the 64-bit FreeBSD arcconf from the sysutils/arcconf port (v5.20.17414). The card is an Adaptec 2120S single-channel U320 SCSI. I realize that is an ancient version of aaccli, but as the aac_linux module isn't present on amd64, I can't use the 32-bit Linux aaccli as I used to when this machine ran i386. Command lines are: aaccli 'open aac0: container list' arcconf getconfig 1 On RELENG_7 dated 2007-12-01 (BETA3), both work fine. On RELENG_7 dated 2007-12-15 (BETA4), aaccli fails with the following error; arcconf continues to work fine: Command Error: The miniport device driver is too old to work with the current AFAAPI.DLL. On RELENG_7_0 dated 2007-12-22 (RC1), aaccli continues to fail as above AND now also arcconf hangs forever after printing its (correct) output; I have to hit ^C to get a prompt back. I don't really care which one works as long as I can make a Nagios plugin out of it. I could put a nasty hack into my plugin to kill the arcconf process after it gets all its output, but a) ew yuck, and b) this may be a kernel bug... Semi-related question: I plan on replacing this SCSI RAID setup with a SAS RAID setup soonish -- anyone tried 3Ware's SAS card yet? It does appear to be supported in the RELENG_7_0 twa driver... and I'm pretty happy with their SATA cards... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror on 7B4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chris H. wrote: Where is the option to create, and install to a gMIRRORED drive-set? If not, why? If not, it possible to install to one drive, mirror all available drives with the data on the installed drive? sysinstall does not provide any simple method of setting up a gmirror RAID-1 itself, but it is fairly easy to escape from the installer and type in a few shell commands to set such a thing up. There are instructions here: http://www.onlamp.com/pub/a/bsd/2005/11/10/FreeBSD_Basics.html Yes, you can convert a drive with a plain vanilla install of FreeBSD on it into part of a gmirror setup easily and without having to worry about rebuilding filesystems. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHe2Op8Mjk52CukIwRCHlZAJ4njIkbhvqNu1b/KmonuuFIfmr6WgCfet5g C25NHpDKIPfUYLFU6ay9T08= =jvLD -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ifconfig options?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://www.freebsd.org/cgi/query-pr.cgi?pr=118987 Ruben van Staveren wrote: Hi Krassimir, Krassimir Slavchev wrote: Hi, 'ifconfig -l [address_family]' does not work correct on RELENG_7 If you suspect a regression in functionality, and you can reproduce it the best thing one can do is submit a problem report with send-pr http://www.freebsd.org/send-pr.html Having them reported on the list may seem nice but stands less chance the item is picked up. Regards, Ruben -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHe2fuxJBWvpalMpkRAkPYAJ4qnL75q97AeQrC/R7KN0OvxtaobACgg24i 1sWVgqtzJ8DMAyYsxWV2Meg= =PpCm -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devfs.rules include rule question in 6.2 release
On Wed, Jan 02, 2008 at 06:23:52PM +1100, Geoff Roberts wrote: Hi, It seems you can't recursively use the include rule specification with devfs in Freebsd 6.2. I couldn't see a note about this in the devfs man page so I'm not sure whether this is expected behaviour or not. The manpages for devfs.conf and devfs.rules do not contain anything about included rulesets because the person who wrote the manual pages doesn't use them. :-) Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgp2MjWRcvzEJ.pgp Description: PGP signature
Re: 7B4: kernel messages garbled
Chris H. wrote: Hello, and happy New Year to all! I'm hoping to update all our servers to 7 in the near future. As such, I'm experimenting with it on one of our less prominent production servers. My procedure for it's installation and usage: download 7-CURRENT disk1 iso (B4) from nearest freebsd mirror install choice - minimum + src make config options, reboot download cvsup-no-gui pkg cvsup ports + src (above procedures performed 2007-12-30) (above procedures again performed on 2007-12-31) In every case, I wiped the hard drive, performing a fresh install. After initial install. Sending a halt, in order to reboot the system results in garbled messages to the console. Specifically, the Syncing disks... message is unintelligible. As does is line preceding it. Also. After syncing the source, I altered/renamed GENERIC and performed build/world/kernel, and install/kernel/world. During the buildworld process I recieved more warnings than I can recall seeing in previous versions = 6. ee (aee) resulted in Illegal instruction... core dumped after the build/install process. FWIW this is on an i386 2 proc MB. Given the many changes in 7, I spent more time reading the doc's and errata than I have spent in previous versions. Thank you for all your time and attention to this matter. It is just a sign that 7 is getting higher concurrency than 6 did. The warnings are probably from the new compiler (gcc 4) which as usual is more strict and more verbose. Try building ee with -ggdb and running a backtrace. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror on 7B4
Hello, and thank you for your reply... Quoting Matthew Seaman [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chris H. wrote: Where is the option to create, and install to a gMIRRORED drive-set? If not, why? If not, it possible to install to one drive, mirror all available drives with the data on the installed drive? sysinstall does not provide any simple method of setting up a gmirror RAID-1 itself, but it is fairly easy to escape from the installer and type in a few shell commands to set such a thing up. There are instructions here: http://www.onlamp.com/pub/a/bsd/2005/11/10/FreeBSD_Basics.html Hah! That's funny. I just picked up a copy of The Complete FreeBSD 4th edition the other day. But haven't had an opportunity to read it yet. Guess I'd better get to it. :) Yes, you can convert a drive with a plain vanilla install of FreeBSD on it into part of a gmirror setup easily and without having to worry about rebuilding filesystems. Seems so. But if you've got much data, and don't have a DVD, or tape magazine on it. You'll need to do the operation (likely) over NFS, and likely requiring a couple of re-boots. As I look at this (gmirror at sysinstall time) closer, it occurs to me that it wouldn't be very difficult to implement response script that asked questions for a basic gmirror setup that would encompass all drives available (seen/understood) and offered to create: swap / /boot /usr /var and simply asked how big the slices should be made. Just a thought. Thanks again for the response. Chris Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHe2Op8Mjk52CukIwRCHlZAJ4njIkbhvqNu1b/KmonuuFIfmr6WgCfet5g C25NHpDKIPfUYLFU6ay9T08= =jvLD -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7B4: kernel messages garbled
Quoting Kris Kennaway [EMAIL PROTECTED]: Chris H. wrote: Hello, and happy New Year to all! I'm hoping to update all our servers to 7 in the near future. As such, I'm experimenting with it on one of our less prominent production servers. My procedure for it's installation and usage: download 7-CURRENT disk1 iso (B4) from nearest freebsd mirror install choice - minimum + src make config options, reboot download cvsup-no-gui pkg cvsup ports + src (above procedures performed 2007-12-30) (above procedures again performed on 2007-12-31) In every case, I wiped the hard drive, performing a fresh install. After initial install. Sending a halt, in order to reboot the system results in garbled messages to the console. Specifically, the Syncing disks... message is unintelligible. As does is line preceding it. Also. After syncing the source, I altered/renamed GENERIC and performed build/world/kernel, and install/kernel/world. During the buildworld process I recieved more warnings than I can recall seeing in previous versions = 6. ee (aee) resulted in Illegal instruction... core dumped after the build/install process. FWIW this is on an i386 2 proc MB. Given the many changes in 7, I spent more time reading the doc's and errata than I have spent in previous versions. Thank you for all your time and attention to this matter. It is just a sign that 7 is getting higher concurrency than 6 did. The warnings are probably from the new compiler (gcc 4) which as usual is more strict and more verbose. Try building ee with -ggdb and running a backtrace. OK. Will do. I'll get back and complain if it failed. :) No. Seriously, I'll try it and report on the results. Thanks for the reply. Chris Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Mixer default values not restored
Hello, I'm running FreeBSD 7.0 RC1 with the following in my kernel configuration: --- device sound device snd_emu10kx --- My soundcard is a Soundblaster Live! In trying to make the rear-channel volume default to 100 I added the following to my /boot/device.hints: --- hint.pcm.1.vol=100 hint.pcm.1.pcm=100 --- This method is suggested on page 164 (section 7.2.4) of the Handbook. The problem is that these mixer levels do not apply: --- $ mixer -f /dev/mixer1 Mixer vol is currently set to 75:75 Mixer pcm is currently set to 75:75 --- There is no problem however in manualy settig these values. Any help is welcome. My machine can - may it be needed - be used as a testbase. Regards, - Jouke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror on 7B4
Quoting Chris H. [EMAIL PROTECTED]: Hello, I seem to remember a similar question being asked in the past. But never ---8---snip---8--- I had originally intended to create a raid mirror on the whole lot of HD's during the install process. But I wasn't presented, nor could I find that option during install. So, due to lack of time, pushed it off till later, and simply installed onto the one HD. Now to my question(s)... Where is the option to create, and install to a gMIRRORED drive-set? ---8---snip---8--- 2) In my cases above, I'm interested in RAID-0 (mirroring for /volume/ not redundancy). OK, my mistake... Seems for my application (RAID0), *gstripe* is what I should be using. Q: But RAID0 provides 0 redundancy. How will you cope with data loss? A: Complete backups occur twice daily and I (we) use IP RAID0 - eg; 2 different servers have/provide the same data, and the DNS provides round-robin. Thereby spreading the requests roughly equal across both servers. So, given my new found knowledge. I felt I should probably ask before potentially clobbering (breaking) the server I'll be attempting this on. Will the following accomplish my goal? Current setup: /dev indicates the following: da0, da0c, da0cs1, da0s1, da0s1c da1, da1c, da1cs1, da1s1, da1s1c da2, da2c, da2cs1, da2s1, da2s1c ...and the following, which FreeBSD is installed on: da3, da3s1, da3s1a, da3s1b, da3s1c, da3s1d All drives are of same size/make/model. Given the above, I intend to issue the following: # gstripe label -v -s 131072 bigstripe \ /dev/da0 /dev/da1 /dev/da2 /dev/da3 # newfs -U /dev/stripe/bigstripe # mount /dev/stripe/bigstripe /bigstripe # echo 'geom_stripe_load=YES' /boot/loader.conf # echo '/dev/stripe/bigstripe /bigstripe ufs rw 2 2' /etc/fstab Or do/should I issue: # gconcat label -v extradisks /dev/da0 /dev/da1 /dev/da2 # gstripe label -v bigstripe /dev/da3 /dev/concat/extradisks # bsdlabel -wB /dev/stripe/bigstripe # newfs -U /dev/stripe/bigstripe # mount /dev/stripe/bigstripe /bigstripe Thank you for all your time and consideration. Chris P.S. I know this is a bit noisy. I intend to keep it brief. Thank you for your understanding. :) -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: aac tool regressions on 7.0-RC1
On Jan 2, 2008, at 3:54 AM, Mike Andrews wrote: Command Error: The miniport device driver is too old to work with the current AFAAPI.DLL. In my experience, this was caused by the firmware rev of the adaptec card. Basically, the combination of FreeBSD, amd64, and Adaptec RAID cards is a bad thing for production systems, and IMO should be avoided. Anyone looking to buy two or three slightly used Adaptec 2230SLP RAID cards? :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Nagios + 6.3-RELEASE == Hung Process
Michael Butler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marc G. Fournier wrote: G'day ... Yesterday, I setup nagios to do some system monitoring ... installed the latest version from ports into a jail, so that I could easily move it around between machines as I upgrade, without losing data ... after about 30 minutes running, I get a second nagios process running (fork?) that takes up ch CPU time as is available, and just hangs there until I kill -9 it ... [ .. ] After searching the 'Net a bit, came across this thread: http://www.nagiosexchange.org/nagios-users.34.0.html?tx_maillisttofaq_pi1%5Bmode%5D=1tx_maillisttofaq_pi1%5BshowUid%5D=7694 That recommends modifying libmap.conf with: [/usr/local/bin/nagios] libpthread.so.2 libthr.so.2 libpthread.so libthr.so Thanks for pointing this out. I've had similar problems with nagios but hadn't found a solution until I saw your pointer. Sadly, my expertise with both thread libraries is sufficiently lacking that I have no clue where to start looking for the cause :-( I have also seen this issue, but have always put it down to the way that we manage our nagios deployments with cfengine. I will try to deploy this change and monitor for the problem to see if it persists. On a side note if you want to use broker modules with nagios from port you need to change the following in the port Makefile in order to make them load properly: From: USE_AUTOTOOLS= autoconf:259 To: SE_AUTOTOOLS= autoconf:259 libltdl:15 I sent an email to the maintainer but got no response and my email did not seem to have affected the last commit to upgrade to 2.10. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
building system's libmilter with poll() support?
What's the procedure to configure buildworld to get sendmail to build libmilter using poll() instead of select()? There is discussion on the postfix mailing list that some high-load performance issues could be solved by switching this, but the fix was to hack the libmilter header file to force the appropriate define to be set, rather than using the sendmail configuration system. This would of course be difficult to preserve across updates and buildworlds... Thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: building system's libmilter with poll() support?
On Jan 2, 2008, at 11:08 AM, Gregory Shapiro wrote: What's the procedure to configure buildworld to get sendmail to build libmilter using poll() instead of select()? Add this to /etc/make.conf: SENDMAIL_CFLAGS+=-D_FFR_WORKERS_POOL [ ... ] Note that bug 118824 has already asked for this to be part of the base. I will likely make that the case for the HEAD and then give it some testing time before MFC'ing. Sweet! Thanks a lot for your help. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Nagios + 6.3-RELEASE == Hung Process
On Wed, 2008-01-02 at 15:26 +, Tom Judge wrote: Michael Butler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm pretty sure that he's getting ready to ship 3.0 release w/ broken threading on FreeBSD. I haven't had time to test it on NetBSD yet, but since it can be fixed by switching up which threading engine you link against on the Free* side of *BSD, its likely a long-term fix in Ports instead of polluting the code with #IFDEF's for FreeBSD-specific POSIX thread nits (it's a hard-sell since the same code works fine on Solaris and Linux w/o issue) What we need is: 1) Nightly builds of Nagios against various releng trees 2) Serious BSD involvement in the project to look at the threading code (beyond me) 3) Bug tracking on the Nagios side I recently proposed #1 and #2 on nagios-user@, but I got a lot of push-back from Andreas. Any type of professional project management improvements that quote Aren't fun are heavily frowned upon. ~BAS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance!
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kris Kennaway wrote:
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.
The results are comparable to:
http://blog.insidesystems.net/articles/2007/04/11/postgresql-scaling-on-6-2-and-7-0
but the same tests running on the same hardware using Linux (kernel
2.6.18-53.1.4.el5 SMP x86_64) are very different.
PostgreSQL is tuned equal.
dmesg:
...
CPU: Intel(R) Xeon(R) CPU X5450 @ 3.00GHz (3000.02-MHz
K8-class CPU)
Origin = GenuineIntel Id = 0x10676 Stepping = 6
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
Features2=0xce3bdSSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,b19
AMD Features=0x2800SYSCALL,LM
AMD Features2=0x1LAHF
Cores per package: 4
usable memory = 8575655936 (8178 MB)
avail memory = 8288337920 (7904 MB)
ACPI APIC Table: HP ProLiant
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
...
test:
sysbench --num-threads=${i} --test=oltp --pgsql-user=bench
--pgsql-db=bench --db-driver=pgsql --max-time=60 --max-requests=0
--oltp-read-only=on run
tuning:
kern.ipc.shmmax=2147483647
kern.ipc.shmall=524288
kern.ipc.semmsl=512
kern.ipc.semmap=256
kern.ipc.somaxconn=2048
kern.maxfiles=65536
vfs.read_max=32
kern.ipc.semmni=256
kern.ipc.semmns=2048
results:
FreeBSD 7.0-BETA4 amd64 (cvsup on 20.12) GENERIC with SCHED_ULE
#threads#transactions/sec user/system
1 500 7.4%,5.3%
5 199030.9%,23.4%
10 251039.9%,35.0%
20 254944.5%,43.5%
40 192129.8%,59.4%
60 158022.7%,70.6%
80 134118.9%,75.9%
100 122716.5%,79.3%
Linux
#threads#transactions/sec
1 693
5 3539
10 5789
20 5791
40 5661
60 5517
80 5401
100 5319
What can be done to improve these results?
Best Regards
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
.
postgresql has some poor default settings on FreeBSD. You need to add:
stats_command_string = off
update_process_title = off
Kris
I use a copy of postgresql.conf file from linux.
Only 'stats_command_string = on' was commented.
Here are results with these settings and lock_manager patch:
#threads#transactions/sec
1 582
5 2154
10 2253
20 2705
40 2215
60 1713
80 1574
100 1256
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (FreeBSD)
iD8DBQFHe7fAxJBWvpalMpkRAipaAJ4uNYByfRxOnPFf4HwG4MqV/zFDIACcC3Pj
W8uGwpdL0oBG0OKHJ/4b/PQ=
=1jGZ
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: building system's libmilter with poll() support?
On Jan 2, 2008, at 11:08 AM, Gregory Shapiro wrote: SENDMAIL_CFLAGS+=-D_FFR_WORKERS_POOL Do I want this one or just -DSM_CONF_POLL ? I'm running into issues with postfix failing to connect to the milter because it is too busy (specifically the dkim milter) and one theory was to use poll to increase the number of connections that the milter can handle. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ifconfig options?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
This patch fixes the problem!
# ifconfig -l
bce0 bce1 lo0
# ifconfig -l ether
bce0 bce1
Thanks
pluknet wrote:
Hi,
On 24/12/2007, Krassimir Slavchev [EMAIL PROTECTED] wrote:
'ifconfig -l [address_family]' does not work correct on RELENG_7
FreeBSD 6.3-BETA2:
# ifconfig -l
em0 em1 plip0 lo0 pflog0
#ifconfig -l ether
em0 em1
But:
FreeBSD 7.0-BETA4:
# ifconfig -l
em0 em1 plip0 lo0 pflog0
#ifconfig -l ether
em0 em1 plip0 lo0 pflog0
I need this functionality to get all ethernet interfaces. Is there other
way to do this?
To revert this functionality try this patch please.
--- /usr/src/sbin/ifconfig/ifconfig.c 2007-12-26 23:25:17.0 +0300
+++ /tmp/ifconfig.c 2007-12-26 23:18:53.0 +0300
@@ -298,9 +298,12 @@
* Are we just listing the interfaces?
*/
if (namesonly) {
- if (ifindex 1)
- printf( );
- fputs(name, stdout);
+ if (afp == NULL || afp-af_af != AF_LINK ||
+ sdl-sdl_type == IFT_ETHER) {
+ if (ifindex 1)
+ printf( );
+ fputs(name, stdout);
+ }
continue;
}
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (FreeBSD)
iD8DBQFHe7nGxJBWvpalMpkRAn7MAKCsjDSf+uDsMQaH1Wxh09TsP43k5wCcDksO
XPkb7nNG2p0wo6XvlvZlb+E=
=p0rg
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: building system's libmilter with poll() support?
Vivek Khera wrote: What's the procedure to configure buildworld to get sendmail to build libmilter using poll() instead of select()? There is discussion on the postfix mailing list that some high-load performance issues could be solved by switching this, but the fix was to hack the libmilter header file to force the appropriate define to be set, rather than using the sendmail configuration system. This would of course be difficult to preserve across updates and buildworlds... The canonical way is to define (at devtools/Site/site.config.m4) : dnl To use poll instead of select : APPENDDEF(`conf_libmilter_ENVDEF',`-DSM_CONF_POLL=1') dnl To use a pool of workers instead of one thread per connection APPENDDEF(`conf_libmilter_ENVDEF',`-D_FFR_WORKERS_POOL=1') Note that the second automatically defines the first one. I don't know how to add this to buildworld. Hope this help... -- --- Jose Marcio MARTINS DA CRUZ http://j-chkmail.ensmp.fr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: building system's libmilter with poll() support?
SENDMAIL_CFLAGS+=-D_FFR_WORKERS_POOL Do I want this one or just -DSM_CONF_POLL ? It would probably be safest to just use -DSM_CONF_POLL as that has had more testing and will get by the select() limits on fd_set. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: building system's libmilter with poll() support?
What's the procedure to configure buildworld to get sendmail to build libmilter using poll() instead of select()? Add this to /etc/make.conf: SENDMAIL_CFLAGS+=-D_FFR_WORKERS_POOL And then rebuild/reinstall libmilter: cd /usr/src/lib/libmilter/ make clean make depend make make install Note that bug 118824 has already asked for this to be part of the base. I will likely make that the case for the HEAD and then give it some testing time before MFC'ing. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror on 7B4
Quoting John Nielsen [EMAIL PROTECTED]: I'm not sure I remember everything from earlier in this thread so I don't know if it's relevant, BUT you can't boot from a gstripe volume (or from a gconcat one AFAIK). Inferring from your fstab example below it doesn't sound like you intend to but I just wanted to be sure. Are you sure? I read that using gmirror requires /kernel to be located in the /boot slice and everything else (all other slices) can be mirrored safely. But in all my reading (man pages, FBSD handbook, asstd articles) I haven't seen anything indicating booting wasn't possible from a gstripe volume. For the record, FSTAB (on da3): /dev/da3s1b none (swap) /dev/da3s1a / /dev/da3s1d /var Thanks for your response. Chris Quoting John Nielsen [EMAIL PROTECTED]: Quoting Chris H. [EMAIL PROTECTED]: Quoting Chris H. [EMAIL PROTECTED]: Hello, I seem to remember a similar question being asked in the past. But never ---8---snip---8--- I had originally intended to create a raid mirror on the whole lot of HD's during the install process. But I wasn't presented, nor could I find that option during install. So, due to lack of time, pushed it off till later, and simply installed onto the one HD. Now to my question(s)... Where is the option to create, and install to a gMIRRORED drive-set? ---8---snip---8--- 2) In my cases above, I'm interested in RAID-0 (mirroring for /volume/ not redundancy). OK, my mistake... Seems for my application (RAID0), *gstripe* is what I should be using. Q: But RAID0 provides 0 redundancy. How will you cope with data loss? A: Complete backups occur twice daily and I (we) use IP RAID0 - eg; 2 different servers have/provide the same data, and the DNS provides round-robin. Thereby spreading the requests roughly equal across both servers. So, given my new found knowledge. I felt I should probably ask before potentially clobbering (breaking) the server I'll be attempting this on. Will the following accomplish my goal? Current setup: /dev indicates the following: da0, da0c, da0cs1, da0s1, da0s1c da1, da1c, da1cs1, da1s1, da1s1c da2, da2c, da2cs1, da2s1, da2s1c ...and the following, which FreeBSD is installed on: da3, da3s1, da3s1a, da3s1b, da3s1c, da3s1d All drives are of same size/make/model. Given the above, I intend to issue the following: # gstripe label -v -s 131072 bigstripe \ /dev/da0 /dev/da1 /dev/da2 /dev/da3 # newfs -U /dev/stripe/bigstripe # mount /dev/stripe/bigstripe /bigstripe # echo 'geom_stripe_load=YES' /boot/loader.conf # echo '/dev/stripe/bigstripe /bigstripe ufs rw 2 2' /etc/fstab Yes, this should be fine (though you may need to do a gstripe load near the beginning). Or do/should I issue: # gconcat label -v extradisks /dev/da0 /dev/da1 /dev/da2 # gstripe label -v bigstripe /dev/da3 /dev/concat/extradisks # bsdlabel -wB /dev/stripe/bigstripe # newfs -U /dev/stripe/bigstripe # mount /dev/stripe/bigstripe /bigstripe No, assuming the disks are (roughly) the same size there's no reason to use gconcat, and in this case doing so will likely hurt performance in addition to adding complexity. gconcat is generally just for JBOD-type scenarios and it sounds like you're after RAID0 which is what gstripe is for. JN Thank you for all your time and consideration. Chris P.S. I know this is a bit noisy. I intend to keep it brief. Thank you for your understanding. :) -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_7 jerky mouse and skipping sound (still a problem -BETA3)
Can you confirm that this fix helped for you? i.e. do you still see the problem? FreeBSD 7.0-RC1 #14: Sun Dec 30 21:50:59 EST 2007 I'm still seeing this problem, but it isn't nearly as bad. I still get some jerky mouse movement, but music doesn't skip now when I'm compiling. I noticed severe sluggishness in X.org the other day when I logged into the console on my 7.0-RC1 box. With firefox open, the mouse was very unresponsive, and at one point I counted and it took ~10 seconds to register a mouse click in firefox. The mouse jerkiness I fixed by starting moused and using /dev/sysmouse instead of /dev/psm0. However, the sluggishness overall in X was still there, and firefox took a lot longer than it should to render pages. I then noticed in my xorg.conf, I had the Depth set to 16-bit (this is on the X.org nv driver). I switched to 24-bit and it is MUCH faster. I ran the wm_torture (http://www.rasterman.com/files/wm_torture-0.1.tar.gz) response test for both 16-bit and 24-bit, and here are the results: 16-bit: Test:map_response MIN: 0.042016s, MAX: 0.046576, AVG: 0.044307 24-bit: Test:map_response MIN: 0.002540s, MAX: 0.005877, AVG: 0.004306 That's over a 10x speed up. I believe those numbers are saying with 16-bit it took an average of 44ms to draw a window, while at 24-bit it took 4.3ms. So, for anyone using the nv (perhaps this applies to other cards/drivers?), check that you are not using 16-bit color depth, as it really seems to hinder performance. Note: this is on an 7.0-RC1 box (running ULE), so the ithread inversion has already been included in the kernel I'm running, so that may have helped as well. But I did not need to set FULL_PREEMPTION or HZ to achieve the good performance. Thanks, Josh ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror on 7B4
Quoting Chris H. [EMAIL PROTECTED]: Quoting Chris H. [EMAIL PROTECTED]: Hello, I seem to remember a similar question being asked in the past. But never ---8---snip---8--- I had originally intended to create a raid mirror on the whole lot of HD's during the install process. But I wasn't presented, nor could I find that option during install. So, due to lack of time, pushed it off till later, and simply installed onto the one HD. Now to my question(s)... Where is the option to create, and install to a gMIRRORED drive-set? ---8---snip---8--- 2) In my cases above, I'm interested in RAID-0 (mirroring for /volume/ not redundancy). OK, my mistake... Seems for my application (RAID0), *gstripe* is what I should be using. Q: But RAID0 provides 0 redundancy. How will you cope with data loss? A: Complete backups occur twice daily and I (we) use IP RAID0 - eg; 2 different servers have/provide the same data, and the DNS provides round-robin. Thereby spreading the requests roughly equal across both servers. So, given my new found knowledge. I felt I should probably ask before potentially clobbering (breaking) the server I'll be attempting this on. Will the following accomplish my goal? Current setup: /dev indicates the following: da0, da0c, da0cs1, da0s1, da0s1c da1, da1c, da1cs1, da1s1, da1s1c da2, da2c, da2cs1, da2s1, da2s1c ...and the following, which FreeBSD is installed on: da3, da3s1, da3s1a, da3s1b, da3s1c, da3s1d All drives are of same size/make/model. Given the above, I intend to issue the following: # gstripe label -v -s 131072 bigstripe \ /dev/da0 /dev/da1 /dev/da2 /dev/da3 # newfs -U /dev/stripe/bigstripe # mount /dev/stripe/bigstripe /bigstripe # echo 'geom_stripe_load=YES' /boot/loader.conf # echo '/dev/stripe/bigstripe /bigstripe ufs rw 2 2' /etc/fstab Yes, this should be fine (though you may need to do a gstripe load near the beginning). Or do/should I issue: # gconcat label -v extradisks /dev/da0 /dev/da1 /dev/da2 # gstripe label -v bigstripe /dev/da3 /dev/concat/extradisks # bsdlabel -wB /dev/stripe/bigstripe # newfs -U /dev/stripe/bigstripe # mount /dev/stripe/bigstripe /bigstripe No, assuming the disks are (roughly) the same size there's no reason to use gconcat, and in this case doing so will likely hurt performance in addition to adding complexity. gconcat is generally just for JBOD-type scenarios and it sounds like you're after RAID0 which is what gstripe is for. JN Thank you for all your time and consideration. Chris P.S. I know this is a bit noisy. I intend to keep it brief. Thank you for your understanding. :) -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror on 7B4
I'm not sure I remember everything from earlier in this thread so I don't know if it's relevant, BUT you can't boot from a gstripe volume (or from a gconcat one AFAIK). Inferring from your fstab example below it doesn't sound like you intend to but I just wanted to be sure. Quoting John Nielsen [EMAIL PROTECTED]: Quoting Chris H. [EMAIL PROTECTED]: Quoting Chris H. [EMAIL PROTECTED]: Hello, I seem to remember a similar question being asked in the past. But never ---8---snip---8--- I had originally intended to create a raid mirror on the whole lot of HD's during the install process. But I wasn't presented, nor could I find that option during install. So, due to lack of time, pushed it off till later, and simply installed onto the one HD. Now to my question(s)... Where is the option to create, and install to a gMIRRORED drive-set? ---8---snip---8--- 2) In my cases above, I'm interested in RAID-0 (mirroring for /volume/ not redundancy). OK, my mistake... Seems for my application (RAID0), *gstripe* is what I should be using. Q: But RAID0 provides 0 redundancy. How will you cope with data loss? A: Complete backups occur twice daily and I (we) use IP RAID0 - eg; 2 different servers have/provide the same data, and the DNS provides round-robin. Thereby spreading the requests roughly equal across both servers. So, given my new found knowledge. I felt I should probably ask before potentially clobbering (breaking) the server I'll be attempting this on. Will the following accomplish my goal? Current setup: /dev indicates the following: da0, da0c, da0cs1, da0s1, da0s1c da1, da1c, da1cs1, da1s1, da1s1c da2, da2c, da2cs1, da2s1, da2s1c ...and the following, which FreeBSD is installed on: da3, da3s1, da3s1a, da3s1b, da3s1c, da3s1d All drives are of same size/make/model. Given the above, I intend to issue the following: # gstripe label -v -s 131072 bigstripe \ /dev/da0 /dev/da1 /dev/da2 /dev/da3 # newfs -U /dev/stripe/bigstripe # mount /dev/stripe/bigstripe /bigstripe # echo 'geom_stripe_load=YES' /boot/loader.conf # echo '/dev/stripe/bigstripe /bigstripe ufs rw 2 2' /etc/fstab Yes, this should be fine (though you may need to do a gstripe load near the beginning). Or do/should I issue: # gconcat label -v extradisks /dev/da0 /dev/da1 /dev/da2 # gstripe label -v bigstripe /dev/da3 /dev/concat/extradisks # bsdlabel -wB /dev/stripe/bigstripe # newfs -U /dev/stripe/bigstripe # mount /dev/stripe/bigstripe /bigstripe No, assuming the disks are (roughly) the same size there's no reason to use gconcat, and in this case doing so will likely hurt performance in addition to adding complexity. gconcat is generally just for JBOD-type scenarios and it sounds like you're after RAID0 which is what gstripe is for. JN Thank you for all your time and consideration. Chris P.S. I know this is a bit noisy. I intend to keep it brief. Thank you for your understanding. :) -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: aac tool regressions on 7.0-RC1
On Wed, Jan 02, 2008 at 10:19:15AM -0500, Vivek Khera wrote: On Jan 2, 2008, at 3:54 AM, Mike Andrews wrote: Command Error: The miniport device driver is too old to work with the current AFAAPI.DLL. In my experience, this was caused by the firmware rev of the adaptec card. Basically, the combination of FreeBSD, amd64, and Adaptec RAID cards is a bad thing for production systems, and IMO should be avoided. In this case it's caused by driver changes obtained from Adaptec's vendor driver. The original poster found that it broke at a specific time which suggested some specific changes that could be at fault. Aaccli doesn't support Adaptec's latest cards, isn't maintained by them any longer, and should be deprecated. Arcconf is the tool that will be supported now, although it does show the behaviour mentioned (hanging after producing the desired output). Adaptec is aware of the issue but I don't have any information on a fix. I'm not aware of any reason to avoid Adaptec RAID cards specifically on amd64 now; there were a number of problems in the past but they should be addressed now. -Ed ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: aac tool regressions on 7.0-RC1
On Wed, 2 Jan 2008, Ed Maste wrote: On Wed, Jan 02, 2008 at 10:19:15AM -0500, Vivek Khera wrote: On Jan 2, 2008, at 3:54 AM, Mike Andrews wrote: Command Error: The miniport device driver is too old to work with the current AFAAPI.DLL. In my experience, this was caused by the firmware rev of the adaptec card. Basically, the combination of FreeBSD, amd64, and Adaptec RAID cards is a bad thing for production systems, and IMO should be avoided. Well, yeah, the error message would seem to point that way, but this is the newest available firmware (v8208) for this particular card. In this case it's caused by driver changes obtained from Adaptec's vendor driver. The original poster found that it broke at a specific time which suggested some specific changes that could be at fault. Aaccli doesn't support Adaptec's latest cards, isn't maintained by them any longer, and should be deprecated. Arcconf is the tool that will be supported now, although it does show the behaviour mentioned (hanging after producing the desired output). Adaptec is aware of the issue but I don't have any information on a fix. For now I'll recode my Nagios plugin to use arcconf, and maybe hack in a kill of the subprocess when it gets all its output. This is a production box so I can't try a lot of kernels in rapid succession. I might be able to borrow another 2120S from someone else to try on a different box though... I'll see if I can do that today or tomorrow so I can play with different aac driver revs and try to selectively back out parts of the commits from 3 weeks ago. Also, if aaccli is depricated, perhaps the sysutils/aaccli port should say something to that effect when you try to install it? I wouldn't have known arcconf even existed if I hadn't stumbled across a mention of it while Googling. :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: aac tool regressions on 7.0-RC1
Ed Maste wrote: On Wed, Jan 02, 2008 at 10:19:15AM -0500, Vivek Khera wrote: On Jan 2, 2008, at 3:54 AM, Mike Andrews wrote: Command Error: The miniport device driver is too old to work with the current AFAAPI.DLL. In my experience, this was caused by the firmware rev of the adaptec card. Basically, the combination of FreeBSD, amd64, and Adaptec RAID cards is a bad thing for production systems, and IMO should be avoided. In this case it's caused by driver changes obtained from Adaptec's vendor driver. The original poster found that it broke at a specific time which suggested some specific changes that could be at fault. Aaccli doesn't support Adaptec's latest cards, isn't maintained by them any longer, and should be deprecated. Arcconf is the tool that will be supported now, although it does show the behaviour mentioned (hanging after producing the desired output). Adaptec is aware of the issue but I don't have any information on a fix. I assume that the use of the newcomm interface by the driver is what triggers the failure of the application. I'm not aware of any reason to avoid Adaptec RAID cards specifically on amd64 now; there were a number of problems in the past but they should be addressed now. The driver has been very solid on 64-bit platforms for many, many years. It was one of the first drivers to support PAE and amd64. However, the application support for the hardware has been more tricky than on i386, and application support is vital these days. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: aac tool regressions on 7.0-RC1
On Jan 2, 2008, at 12:45 PM, Ed Maste wrote: I'm not aware of any reason to avoid Adaptec RAID cards specifically on amd64 now; there were a number of problems in the past but they should be addressed now. My main concern is that there is no *reliable* way to monitor the status of an Adaptec RAID system on FreeBSD/amd64. Like I said before, if anyone wants 3 2230SLP RAID cards cheap, give me a holler. :-) I've retired them (one of them is still new in box). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: aac tool regressions on 7.0-RC1
On Jan 2, 2008, at 1:06 PM, Mike Andrews wrote: In my experience, this was caused by the firmware rev of the adaptec card. Basically, the combination of FreeBSD, amd64, and Adaptec RAID cards is a bad thing for production systems, and IMO should be avoided. Well, yeah, the error message would seem to point that way, but this is the newest available firmware (v8208) for this particular card. For me, it was the latest firmware on the 2230SLP cards that broke the aaccli program. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror on 7B4
Quoting Chris H. [EMAIL PROTECTED]: Quoting John Nielsen [EMAIL PROTECTED]: I'm not sure I remember everything from earlier in this thread so I don't know if it's relevant, BUT you can't boot from a gstripe volume (or from a gconcat one AFAIK). Inferring from your fstab example below it doesn't sound like you intend to but I just wanted to be sure. Are you sure? I read that using gmirror requires /kernel to be located in the /boot slice and everything else (all other slices) can be mirrored safely. But in all my reading (man pages, FBSD handbook, asstd articles) I haven't seen anything indicating booting wasn't possible from a gstripe volume. Yes, I'm sure. In order to bootstrap the system, the BIOS needs to know how to read the operating system from the disk. FreeBSD's own loader also relies on BIOS calls for disk reads until the kernel is loaded and executed. When using a hardware RAID controller its own BIOS runs before the OS boot so it can handle disk I/O from the RAID volumes it knows about. When using purely software RAID such as gstripe, the computer knows nothing about any volumes, it just knows about the individual disks. If you tell it to boot from disk 1, it will try to boot from disk one and then choke since it will only get at most 1 stripe's worth of contiguous useful data (the next stripe being stored on a different disk). For gmirror this doesn't matter, since an individual disk can be used to load the kernel without any knowledge of RAID volumes. Nothing needs can write to the disk until init mounts the root partition read-write (presumably using gmirror) so the volume integrity is not affected. The simplest (IMO, although knowledge of fdisk, bsdlabel, newfs and what boot blocks go where may be required, along with using dump/restore on occasion) approach is to make / its own small partition on a gmirror volume and then create gstripe (or whatever) volumes from the remainder of the disks for the rest of the mountpoints. That means you'll be handing slices or partitions to gmirror, gstripe and friends rather than whole raw disks, but that's okay. It is possible to have only /boot on the actual boot device/partition (with the rest of / elsewhere) but in this scenario that just adds complexity. Most of the few hundred MB that / typically requires are in /boot anyway. If you want specific advice for a specific scenario you can probably get it, but you'll have to supply some additional details. For instance I'm still not sure if this is a new install or an upgrade (even after re-reading the entire thread), or if da3 is the same size as da0-2. Doing what you describe below will blow away the existing contents of da3 and the other disks, and/or won't be allowed if anything on da3 is currently mounted/running. Also you should stop saying mirror if you mean stripe or JBOD. :) JN For the record, FSTAB (on da3): /dev/da3s1b none (swap) /dev/da3s1a / /dev/da3s1d /var Thanks for your response. Chris Quoting John Nielsen [EMAIL PROTECTED]: Quoting Chris H. [EMAIL PROTECTED]: Quoting Chris H. [EMAIL PROTECTED]: Hello, I seem to remember a similar question being asked in the past. But never ---8---snip---8--- I had originally intended to create a raid mirror on the whole lot of HD's during the install process. But I wasn't presented, nor could I find that option during install. So, due to lack of time, pushed it off till later, and simply installed onto the one HD. Now to my question(s)... Where is the option to create, and install to a gMIRRORED drive-set? ---8---snip---8--- 2) In my cases above, I'm interested in RAID-0 (mirroring for /volume/ not redundancy). OK, my mistake... Seems for my application (RAID0), *gstripe* is what I should be using. Q: But RAID0 provides 0 redundancy. How will you cope with data loss? A: Complete backups occur twice daily and I (we) use IP RAID0 - eg; 2 different servers have/provide the same data, and the DNS provides round-robin. Thereby spreading the requests roughly equal across both servers. So, given my new found knowledge. I felt I should probably ask before potentially clobbering (breaking) the server I'll be attempting this on. Will the following accomplish my goal? Current setup: /dev indicates the following: da0, da0c, da0cs1, da0s1, da0s1c da1, da1c, da1cs1, da1s1, da1s1c da2, da2c, da2cs1, da2s1, da2s1c ...and the following, which FreeBSD is installed on: da3, da3s1, da3s1a, da3s1b, da3s1c, da3s1d All drives are of same size/make/model. Given the above, I intend to issue the following: # gstripe label -v -s 131072 bigstripe \ /dev/da0 /dev/da1 /dev/da2 /dev/da3 # newfs -U /dev/stripe/bigstripe # mount /dev/stripe/bigstripe /bigstripe # echo 'geom_stripe_load=YES' /boot/loader.conf # echo '/dev/stripe/bigstripe /bigstripe ufs rw 2 2' /etc/fstab Yes, this should be fine (though you may need to do a gstripe load near the beginning). Or do/should I issue: # gconcat label
Re: Nagios + 6.3-RELEASE == Hung Process
On 03/01/2008, at 1:56 AM, Tom Judge wrote: I have also seen this issue, but have always put it down to the way that we manage our nagios deployments with cfengine. I will try to deploy this change and monitor for the problem to see if it persists. I hope I can confirm your frustrations. There is a threading issue with Nagios when it's binaries are linked against libpthread(3) threading library, the default on recent FreeBSD 5.x releases and all 6.x releases. The issue is random and extremely difficult to track down with the symptoms being a second Nagios process sitting on the system hanging a CPU. Be rest assured that I have been working on it, and have seen it on one system of mine. Changes have been submitted for net-mgmt/nagios-devel (aka Nagios 3.0.r1)) to force the build process to link against libthr(3) where available, removing the need to map libpthread() out with /etc/ libmap.conf. If this goes well, as stated in the PR, i'll back-port it to net-mgmt/nagios (aka Nagios 2.10) in the next few days. If anyone out there is running net-mgmt/nagios-devel and feels like trying it for me, see ports/119246 and drop me an email with a before and after ldd /usr/local/bin/nagios. On a side note if you want to use broker modules with nagios from port you need to change the following in the port Makefile in order to make them load properly: From: USE_AUTOTOOLS= autoconf:259 To: SE_AUTOTOOLS= autoconf:259 libltdl:15 I sent an email to the maintainer but got no response and my email did not seem to have affected the last commit to upgrade to 2.10 I did receive that email and the changes went in with the last commit of net-mgmt/nagios-devel to test. No issues have arisen so i'll be back-porting it to net-mgmt/nagios soon for you. There also has been a rather large ports freeze which delayed the upgrade to Nagios 2.10, that PR was submitted on the 1st of November and committed on the 13th of December. Unfortunately your email fell somewhere in the middle, apologies for not letting you know. Jarrod. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
gstripe on 7B4 - was: gmirror on 7B4
Quoting John Nielsen [EMAIL PROTECTED]: Quoting Chris H. [EMAIL PROTECTED]: Quoting John Nielsen [EMAIL PROTECTED]: I'm not sure I remember everything from earlier in this thread so I ---8---snip---8--- to be sure. Are you sure? ---8---snip---8--- volume. Yes, I'm sure. In order to bootstrap the system, the BIOS needs to know how to read the operating system from the disk. FreeBSD's own loader also relies on BIOS calls for disk reads until the kernel is loaded and executed. When using a hardware RAID controller its own BIOS runs before the OS boot so it can handle disk I/O from the RAID volumes it knows about. When using purely software RAID such as gstripe, the computer knows nothing about any volumes, it just knows about the individual disks. If you tell it to boot from disk 1, it will try to boot from disk one and then choke since it will only get at most 1 stripe's worth of contiguous useful data (the next stripe being stored on a different disk). For gmirror this doesn't matter, since an individual disk can be used to load the kernel without any knowledge of RAID volumes. Nothing needs can write to the disk until init mounts the root partition read-write (presumably using gmirror) so the volume integrity is not affected. The simplest (IMO, although knowledge of fdisk, bsdlabel, newfs and what boot blocks go where may be required, along with using dump/restore on occasion) approach is to make / its own small partition on a gmirror volume and then create gstripe (or whatever) volumes from the remainder of the disks for the rest of the mountpoints. That means you'll be handing slices or partitions to gmirror, gstripe and friends rather than whole raw disks, but that's okay. It is possible to have only /boot on the actual boot device/partition (with the rest of / elsewhere) but in this scenario that just adds complexity. Most of the few hundred MB that / typically requires are in /boot anyway. If you want specific advice for a specific scenario you can probably get it, but you'll have to supply some additional details. For instance I'm still not sure if this is a new install or an upgrade Both: I was wondering why gmirror wasn't an option during sysinstall (the creation, and installation to). Which begged the question - now that it's installed... (even after re-reading the entire thread), or if da3 is the same size as da0-2. Doing what you describe below will blow away the existing contents of da3 and the other disks, and/or won't be allowed if anything on da3 is currently mounted/running. Also you should stop saying mirror if you mean stripe or JBOD. :) Quite right. Again, my bad. I'm sorry this became so convoluted. It seemed so clear at first. But as it started a question about gmirror, and my almost immediate discovery that gmirror doesn't do RAID0, as I required. Turned it into gstripe. I thought I had managed to make the transition smoothly. But as you effectively indicated, no dice. Sorry. :( Thank you *very* much for your informative, and thoughtful replies - and patience. :) OK, in the final analysis I've decided (now that it's (7B4) installed...) I'll just keep /boot, /root (and presumably /dev) on the already available and running install disk (da3). Then perform: # gstripe label -v -s 131072 bigstripe \ /dev/da0 /dev/da1 /dev/da2 # newfs -U /dev/stripe/bigstripe # mkdir /bigstripe # mount /dev/stripe/bigstripe /bigstripe # echo 'geom_stripe_load=YES' /boot/loader.conf # echo '/dev/stripe/bigstripe /bigstripe ufs rw 2 2' /etc/fstab # cd /var # tar cf - . | (cd /bigstripe; tar xvf - and repeating the above two lines for /bin, /compat, /dist, /entropy, /etc, /lib, /libexec, /media, /mnt, /proc, /rescue, /sbin, /sys, /tmp, and /usr moving and remaking /home. Then deleting and re-creating the above (/bin, /compat, etc...). Then modify /etc/fstab to read /dev/stripe/bigstripe / ufs rw 2 2 unmount /bigstripe mount / Done. Yes? Maybe I'm overestimating the FreeBSD file system. But this seems plausible. Thanks to everyones time, consideration (and patience). Chris JN For the record, FSTAB (on da3): /dev/da3s1b none (swap) /dev/da3s1a / /dev/da3s1d /var Thanks for your response. Chris A *little* history, perhaps helps context... ---8---snip---8--- OK, my mistake... Seems for my application (RAID0), *gstripe* is what I should be using. Q: But RAID0 provides 0 redundancy. How will you cope with data loss? A: Complete backups occur twice daily and I (we) use IP RAID0 - eg; 2 different servers have/provide the same data, and the DNS provides round-robin. Thereby spreading the requests roughly equal across both servers. So, given my new found knowledge. I felt I should probably ask before potentially clobbering (breaking) the server I'll be attempting this on. Will the following accomplish my goal? Current setup: /dev indicates the following: da0, da0c, da0cs1, da0s1, da0s1c da1, da1c, da1cs1, da1s1, da1s1c da2, da2c,
HEADSUP: new wiki page: State of Packages on Sparc64
I've just posted a message with that title to sparc64@ with crosspost to [EMAIL PROTECTED] If you're interested in deciding on where we're going with sparc64, I invite you to join that thread. (Please don't reply to this message; 2 lists is probably one too many). mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Nagios + 6.3-RELEASE == Hung Process
Jarrod Sayers wrote: On 03/01/2008, at 1:56 AM, Tom Judge wrote: I have also seen this issue, but have always put it down to the way that we manage our nagios deployments with cfengine. I will try to deploy this change and monitor for the problem to see if it persists. I hope I can confirm your frustrations. There is a threading issue with Nagios when it's binaries are linked against libpthread(3) threading library, the default on recent FreeBSD 5.x releases and all 6.x releases. The issue is random and extremely difficult to track down with the symptoms being a second Nagios process sitting on the system hanging a CPU. Be rest assured that I have been working on it, and have seen it on one system of mine. Not sure if this is related at all but out of the 3 nagios deployments we have here I have only ever seen it on one (It currently has 2 nagios threads spinning CPU time atm). The differences on that server are: * It is amd64 compared to i386 * It also runs ndo2db from ndoutils 1.4b7 All the systems run 6.2-RELEASE-p5 and nagios-2.9_1, they are also all patched with gnu libltdl patch below. Don't know if that info is of any use to you. Changes have been submitted for net-mgmt/nagios-devel (aka Nagios 3.0.r1)) to force the build process to link against libthr(3) where available, removing the need to map libpthread() out with /etc/libmap.conf. If this goes well, as stated in the PR, i'll back-port it to net-mgmt/nagios (aka Nagios 2.10) in the next few days. If anyone out there is running net-mgmt/nagios-devel and feels like trying it for me, see ports/119246 and drop me an email with a before and after ldd /usr/local/bin/nagios. On a side note if you want to use broker modules with nagios from port you need to change the following in the port Makefile in order to make them load properly: From: USE_AUTOTOOLS= autoconf:259 To: SE_AUTOTOOLS= autoconf:259 libltdl:15 I sent an email to the maintainer but got no response and my email did not seem to have affected the last commit to upgrade to 2.10 I did receive that email and the changes went in with the last commit of net-mgmt/nagios-devel to test. No issues have arisen so i'll be back-porting it to net-mgmt/nagios soon for you. There also has been a rather large ports freeze which delayed the upgrade to Nagios 2.10, that PR was submitted on the 1st of November and committed on the 13th of December. Unfortunately your email fell somewhere in the middle, apologies for not letting you know. Thanks for this, I currently maintain the patch on our build servers. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Nagios + 6.3-RELEASE == Hung Process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Wednesday, January 02, 2008 22:54:33 + Tom Judge [EMAIL PROTECTED] wrote: Not sure if this is related at all but out of the 3 nagios deployments we have here I have only ever seen it on one (It currently has 2 nagios threads spinning CPU time atm). The differences on that server are: * It is amd64 compared to i386 I never tried on i386, but in my case it was an amd64 system as well ... not sure if that is relevant or not ... has anyone seen this problem *with* i386? - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHfB0s4QvfyHIvDvMRAudqAKCuiXkAYPL5goXbmlvJjylpMlqUIwCgiRfM m15NQlmqpRtO/MtEXR7m+RU= =utJ9 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance!
Krassimir Slavchev wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kris Kennaway wrote:
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.
The results are comparable to:
http://blog.insidesystems.net/articles/2007/04/11/postgresql-scaling-on-6-2-and-7-0
but the same tests running on the same hardware using Linux (kernel
2.6.18-53.1.4.el5 SMP x86_64) are very different.
PostgreSQL is tuned equal.
dmesg:
...
CPU: Intel(R) Xeon(R) CPU X5450 @ 3.00GHz (3000.02-MHz
K8-class CPU)
Origin = GenuineIntel Id = 0x10676 Stepping = 6
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
Features2=0xce3bdSSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,b19
AMD Features=0x2800SYSCALL,LM
AMD Features2=0x1LAHF
Cores per package: 4
usable memory = 8575655936 (8178 MB)
avail memory = 8288337920 (7904 MB)
ACPI APIC Table: HP ProLiant
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
...
test:
sysbench --num-threads=${i} --test=oltp --pgsql-user=bench
--pgsql-db=bench --db-driver=pgsql --max-time=60 --max-requests=0
--oltp-read-only=on run
tuning:
kern.ipc.shmmax=2147483647
kern.ipc.shmall=524288
kern.ipc.semmsl=512
kern.ipc.semmap=256
kern.ipc.somaxconn=2048
kern.maxfiles=65536
vfs.read_max=32
kern.ipc.semmni=256
kern.ipc.semmns=2048
results:
FreeBSD 7.0-BETA4 amd64 (cvsup on 20.12) GENERIC with SCHED_ULE
#threads#transactions/sec user/system
1 500 7.4%,5.3%
5 199030.9%,23.4%
10 251039.9%,35.0%
20 254944.5%,43.5%
40 192129.8%,59.4%
60 158022.7%,70.6%
80 134118.9%,75.9%
100 122716.5%,79.3%
Linux
#threads#transactions/sec
1 693
5 3539
10 5789
20 5791
40 5661
60 5517
80 5401
100 5319
What can be done to improve these results?
Best Regards
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
.
postgresql has some poor default settings on FreeBSD. You need to add:
stats_command_string = off
update_process_title = off
Kris
I use a copy of postgresql.conf file from linux.
Only 'stats_command_string = on' was commented.
Here are results with these settings and lock_manager patch:
#threads#transactions/sec
1 582
5 2154
10 2253
20 2705
40 2215
60 1713
80 1574
100 1256
Please enable LOCK_PROFILING in your kernel and then do
sysctl debug.lock.prof.enable=1
run the test with 8 threads
sysctl debug.lock.prof.enable=0
and send me the output of
sysctl debug.lock.prof.stats
Kris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance!
Kris Kennaway wrote:
Krassimir Slavchev wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kris Kennaway wrote:
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.
The results are comparable to:
http://blog.insidesystems.net/articles/2007/04/11/postgresql-scaling-on-6-2-and-7-0
but the same tests running on the same hardware using Linux (kernel
2.6.18-53.1.4.el5 SMP x86_64) are very different.
PostgreSQL is tuned equal.
dmesg:
...
CPU: Intel(R) Xeon(R) CPU X5450 @ 3.00GHz (3000.02-MHz
K8-class CPU)
Origin = GenuineIntel Id = 0x10676 Stepping = 6
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
Features2=0xce3bdSSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,b19
AMD Features=0x2800SYSCALL,LM
AMD Features2=0x1LAHF
Cores per package: 4
usable memory = 8575655936 (8178 MB)
avail memory = 8288337920 (7904 MB)
ACPI APIC Table: HP ProLiant
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
...
test:
sysbench --num-threads=${i} --test=oltp --pgsql-user=bench
--pgsql-db=bench --db-driver=pgsql --max-time=60 --max-requests=0
--oltp-read-only=on run
tuning:
kern.ipc.shmmax=2147483647
kern.ipc.shmall=524288
kern.ipc.semmsl=512
kern.ipc.semmap=256
kern.ipc.somaxconn=2048
kern.maxfiles=65536
vfs.read_max=32
kern.ipc.semmni=256
kern.ipc.semmns=2048
results:
FreeBSD 7.0-BETA4 amd64 (cvsup on 20.12) GENERIC with SCHED_ULE
#threads#transactions/sec user/system
1 500 7.4%,5.3%
5 199030.9%,23.4%
10 251039.9%,35.0%
20 254944.5%,43.5%
40 192129.8%,59.4%
60 158022.7%,70.6%
80 134118.9%,75.9%
100 122716.5%,79.3%
Linux
#threads#transactions/sec
1 693
5 3539
10 5789
20 5791
40 5661
60 5517
80 5401
100 5319
What can be done to improve these results?
Best Regards
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
.
postgresql has some poor default settings on FreeBSD. You need to add:
stats_command_string = off
update_process_title = off
Kris
I use a copy of postgresql.conf file from linux.
Only 'stats_command_string = on' was commented.
Here are results with these settings and lock_manager patch:
#threads#transactions/sec
1 582
5 2154
10 2253
20 2705
40 2215
60 1713
80 1574
100 1256
Please enable LOCK_PROFILING in your kernel and then do
sysctl debug.lock.prof.enable=1
run the test with 8 threads
sysctl debug.lock.prof.enable=0
and send me the output of
sysctl debug.lock.prof.stats
Kris
Are you using postgresql 8.1 or older? It didn't have the
update_process_title option to disable the setproctitle() calls that
have a large performance penalty on FreeBSD. Try with 8.2 or hack the
source to disable it.
Kris
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Nagios + 6.3-RELEASE == Hung Process
On Wed, Jan 02, 2008 at 07:24:28PM -0400, Marc G. Fournier wrote: - --On Wednesday, January 02, 2008 22:54:33 + Tom Judge [EMAIL PROTECTED] wrote: Not sure if this is related at all but out of the 3 nagios deployments we have here I have only ever seen it on one (It currently has 2 nagios threads spinning CPU time atm). The differences on that server are: * It is amd64 compared to i386 I never tried on i386, but in my case it was an amd64 system as well ... not sure if that is relevant or not ... has anyone seen this problem *with* i386? Yes. We run Nagios on an i386 machine (dual Athlon MP 1800+), and I first saw this problem with a build of 6-STABLE as of 2007-10-04, and it continues (if I don't use the libmap.conf settings) with the running system of 6.3-PRERLEASE as of 2007-12-18 and nagios-2.10 (from ports of same date). -- greg byshenk - [EMAIL PROTECTED] - Leiden, NL ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Nagios + 6.3-RELEASE == Hung Process
On Wed, 2 Jan 2008, Tom Judge wrote: Jarrod Sayers wrote: I hope I can confirm your frustrations. There is a threading issue with Nagios when it's binaries are linked against libpthread(3) threading library, the default on recent FreeBSD 5.x releases and all 6.x releases. The issue is random and extremely difficult to track down with the symptoms being a second Nagios process sitting on the system hanging a CPU. Be rest assured that I have been working on it, and have seen it on one system of mine. Not sure if this is related at all but out of the 3 nagios deployments we have here I have only ever seen it on one (It currently has 2 nagios threads spinning CPU time atm). The differences on that server are: * It is amd64 compared to i386 * It also runs ndo2db from ndoutils 1.4b7 All the systems run 6.2-RELEASE-p5 and nagios-2.9_1, they are also all patched with gnu libltdl patch below. Don't know if that info is of any use to you. That's actually good to know, as you're now (unless I am mistaken) the first user to contact me about this problem on non-i386 systems. One user, plus myself, have also seen the issue under Nagios 3.x, both on i386 systems though. I also have a net-mgmt/ndoutils port in the works (less the database support for now) which also has the same issue so using broker modules doesn't seem to affect the outcome. My gut feeling is that it's not an architecture issue but more an interoperability issue between the Nagios threading code and the libpthread() threading library. [yoink] I did receive that email and the changes went in with the last commit of net-mgmt/nagios-devel to test. No issues have arisen so i'll be back-porting it to net-mgmt/nagios soon for you. There also has been a rather large ports freeze which delayed the upgrade to Nagios 2.10, that PR was submitted on the 1st of November and committed on the 13th of December. Unfortunately your email fell somewhere in the middle, apologies for not letting you know. Thanks for this, I currently maintain the patch on our build servers. No worries, I will look at bundling in the change with the libthr() fix over the next few days. Thanks for pointing that out too as it was a bug instead of a feature request, as on systems where the library was available, the build process would link to it. Hmm... Jarrod. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gstripe on 7B4 - was: gmirror on 7B4
On 1/2/08, Chris H. [EMAIL PROTECTED] wrote: OK, in the final analysis I've decided (now that it's (7B4) installed...) I'll just keep /boot, /root (and presumably /dev) on the already available and running install disk (da3). Then perform: # gstripe label -v -s 131072 bigstripe \ /dev/da0 /dev/da1 /dev/da2 # newfs -U /dev/stripe/bigstripe # mkdir /bigstripe # mount /dev/stripe/bigstripe /bigstripe # echo 'geom_stripe_load=YES' /boot/loader.conf # echo '/dev/stripe/bigstripe /bigstripe ufs rw 2 2' /etc/fstab # cd /var # tar cf - . | (cd /bigstripe; tar xvf - and repeating the above two lines for /bin, /compat, /dist, /entropy, /etc, /lib, /libexec, /media, /mnt, /proc, /rescue, /sbin, /sys, /tmp, and /usr moving and remaking /home. Then deleting and re-creating the above (/bin, /compat, etc...). Then modify /etc/fstab to read /dev/stripe/bigstripe / ufs rw 2 2 unmount /bigstripe mount / Done. Yes? Maybe I'm overestimating the FreeBSD file system. But this seems plausible. You could have / (root) also on /bigstripe, if you do something similar to the way that ZFSonRoot (http://wiki.freebsd.org/ZFSOnRoot) is done. Scot ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Nagios + 6.3-RELEASE == Hung Process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marc G. Fournier wrote: I never tried on i386, but in my case it was an amd64 system as well ... not sure if that is relevant or not ... has anyone seen this problem *with* i386? When I read about it, I was in the middle of upgrading the problem machine to 7-stable - which now reports as follows: FreeBSD 7.0-PRERELEASE #0: Tue Jan 1 22:12:02 EST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/AARON Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel Pentium III (701.59-MHz 686-class CPU) Origin = GenuineIntel Id = 0x681 Stepping = 1 Features=0x387f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE real memory = 1073479680 (1023 MB) avail memory = 1041297408 (993 MB) kbd1 at kbdmux0 acpi0: INTEL TR440BXA on motherboard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHfDKWQv9rrgRC1JIRAgTzAJ0T4HwQcR8kSj+iuKL90S2oz5EWMACeLPqd pBkMfN9J08zv+ibT3TgcYHA= =vmkg -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Nagios + 6.3-RELEASE == Hung Process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Thursday, January 03, 2008 11:05:16 +1030 Jarrod Sayers [EMAIL PROTECTED] wrote: That's actually good to know, as you're now (unless I am mistaken) the first user to contact me about this problem on non-i386 systems. One user, plus myself, have also seen the issue under Nagios 3.x, both on i386 systems though. I also have a net-mgmt/ndoutils port in the works (less the database support for now) which also has the same issue so using broker modules doesn't seem to affect the outcome. My gut feeling is that it's not an architecture issue but more an interoperability issue between the Nagios threading code and the libpthread() threading library. As noted in my original report, this isn't a nagios issue per se ... my first experience with this issue was with Azureus/java ... so its a 'threading issue in general' ... - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHfDm94QvfyHIvDvMRAtZkAKCf4z6csc+YaXBS1/UMurQ3NIqXDgCeLCif jplg0JQzX4xKQEgJsVy/nGY= =dA7G -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
