Re: 6.0 release date and stability
Brett Glass wrote: At 06:34 PM 10/15/2005, David Syphers wrote: http://www.freebsd.org/releases/6.0R/todo.html Linked to from the schedule page... Been there. Want to get folks' opinions, and also more detail than is likely to appear on th epage. Good to see alot of it just needs testing now compared to the last time I looked ( ~2weeks ). I also thought that FreeBSD was going to implement the same installer as DragonFly-BSD? Will 6 support SSE3? I noticed that 5.4 does not and only finds SSE SSE2, what about SSE3? I still think I'll wait for 6.1 before installing it anyway. Jayton ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpu frequency on 6.0
On Sun, Oct 16, 2005 at 06:54:12AM +0200, Zoran Kolic wrote: I'd like to know, prior to install upcoming 6.0, about putting cpu into cooler mo- de. On 5.4 and amd64 2800+ cpu (754, 0.13) with acpi_ppc, it works fine and temperature is just over 30. Could I do the same with device cpufreq and powerd_enable? Yes, it should work without any problem. (if you want to retain the characteristic of the acpi_ppc driver just put: powerd_flags=-r 2 into your rc.conf) -- Markus ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.0 release date and stability
On Sat, 15 Oct 2005 23:03:53 -0400 Joshua Coombs [EMAIL PROTECTED] wrote: For what it's worth, on UP, my 386 (stop laughing) is showing twice the inbound and outbound tcp throughput across multiple apps compared to 4.11. Disk throughput is slightly higher, but nothing super impressive. If 6.0 can show gains on a 386, that tells me there is some actual merit to the changes. The news I read about fFreeBSD-6.0 is quit good lately. I might even upgrade my 5.4 box. I'm told it will be a rather smooth proces. The *ONLY* question is: will I need to *recompile* all installed ports if I go from 5.4 to 6.0 release? -- dick -- http://nagual.st/ -- PGP/GnuPG key: F86289CE ++ Running FreeBSD 4.11-stable ++ FreeBSD 5.4 + Nai tiruvantel ar vayuvantel i Valar tielyanna nu vilja ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.0 release date and stability
On Sun, 16 Oct 2005, dick hoogendijk wrote: On Sat, 15 Oct 2005 23:03:53 -0400 Joshua Coombs [EMAIL PROTECTED] wrote: For what it's worth, on UP, my 386 (stop laughing) is showing twice the inbound and outbound tcp throughput across multiple apps compared to 4.11. Disk throughput is slightly higher, but nothing super impressive. If 6.0 can show gains on a 386, that tells me there is some actual merit to the changes. The news I read about fFreeBSD-6.0 is quit good lately. I might even upgrade my 5.4 box. I'm told it will be a rather smooth proces. For my private Desktop machine I didn't run into any problems - and I am no kind of FreeBSD guru. The *ONLY* question is: will I need to *recompile* all installed ports if I go from 5.4 to 6.0 release? Probably not, but there are about 13000 (or so) ports available. I guess you will have to try and find out. You should be cautious if you depend on OpenOffice.org , this stuff is always quite sensitive, though I have got 2.0Beta running very well. Regards, Uli. -- dick -- http://nagual.st/ -- PGP/GnuPG key: F86289CE ++ Running FreeBSD 4.11-stable ++ FreeBSD 5.4 + Nai tiruvantel ar vayuvantel i Valar tielyanna nu vilja ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] * * Peter Ulrich Kruppa - Wuppertal - Germany * * ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Disk 100% busy
I am trying to diagnose a problem whereby a virus scanner (clam antivirus) is taking too long to scan attachments on a mail server. We have an attachment limitation of 20MB and an attachment of 7-20MB can take over 3 minutes to scan. This often causes the sending mail server to timeout and resend the mail. In this case, my mail gateway is is a dual 3.06GHz Xeon with 1GB of ram and 2 36GB 15krpm drives in a raid-1 on a smart array 6i (cciss) controller. I am running FreeBSD 5.4-RELEASE-p1. Systat -vmstat reports the disk mirror is 100% busy at all times on this machine, with an average of around 300 tps at 15KB/t. This seems wrong to me, as these numbers are maintained even when the system doesn't otherwise appear busy. We don't seem to be swamped by log writes. How can I tell what's generating these disk writes? At the moment the 100% disk utilization is the only thing I can see that would cause the scanning delay. The machine overall is sluggish with file operations. -Will -- Will Saxon Systems Programmer, Network Services University of Florida Department of Housing Phone: (352) 392-2171 x10148 Email: [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: 6.0 release date and stability
On Sun, 16 Oct 2005 13:57:52 +0200, dick hoogendijk [EMAIL PROTECTED] wrote: On Sat, 15 Oct 2005 23:03:53 -0400 Joshua Coombs [EMAIL PROTECTED] wrote: For what it's worth, on UP, my 386 (stop laughing) is showing twice the inbound and outbound tcp throughput across multiple apps compared to 4.11. Disk throughput is slightly higher, but nothing super impressive. If 6.0 can show gains on a 386, that tells me there is some actual merit to the changes. The news I read about fFreeBSD-6.0 is quit good lately. I might even upgrade my 5.4 box. I'm told it will be a rather smooth proces. The *ONLY* question is: will I need to *recompile* all installed ports if I go from 5.4 to 6.0 release? There are a couple of options: 1. Do not remove old (5.4) libraries. All 5.4 libs wil still be found. 2. Remove old libraries and install ports/misc/compat5x. All 5.4 lib wil still be found. 3. Remove old libraries and use /etc/libmap.conf to map the old libs on the new ones. 4. Recompile every port, so all dependencies are the 6.0 libs. Ronald. -- Ronald Klop Amsterdam, The Netherlands ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: linking problems with heimdal in base (ports version works)
On Sunday, 16. October 2005 09:06, Igor Pokrovsky wrote: On Fri, Oct 14, 2005 at 09:49:51PM +0200, Michael Nottebrock wrote: On Friday, 14. October 2005 21:11, Igor Pokrovsky wrote: Still, isn't it strange that the kerberos libs don't have any dependencies registered? A quick check shows that they are almost the only libs in /usr/lib that have zero output from ldd. Probably they are statically linked. No, static libraries don't come with an .so extension. :-) No, you missed my point. I mean that kerberos libs are dynamic but linked against other libraries statically. If they were, there would be no problem in the first place. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp7dhgifPldu.pgp Description: PGP signature
Re: linking problems with heimdal in base (ports version works)
On Sun, Oct 16, 2005 at 06:35:51PM +0200, Michael Nottebrock wrote: On Sunday, 16. October 2005 09:06, Igor Pokrovsky wrote: On Fri, Oct 14, 2005 at 09:49:51PM +0200, Michael Nottebrock wrote: On Friday, 14. October 2005 21:11, Igor Pokrovsky wrote: Still, isn't it strange that the kerberos libs don't have any dependencies registered? A quick check shows that they are almost the only libs in /usr/lib that have zero output from ldd. Probably they are statically linked. No, static libraries don't come with an .so extension. :-) No, you missed my point. I mean that kerberos libs are dynamic but linked against other libraries statically. If they were, there would be no problem in the first place. Sorry, it seems I missed a part of the thread. -ip -- The love letter you finally got the courage to send will be delayed in the mail long enough for you to make a fool of yourself in person. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.0 release date and stability
On Sunday, 16. October 2005 18:34, Ronald Klop wrote: There are a couple of options: 1. Do not remove old (5.4) libraries. All 5.4 libs wil still be found. 2. Remove old libraries and install ports/misc/compat5x. All 5.4 lib wil still be found. 3. Remove old libraries and use /etc/libmap.conf to map the old libs on the new ones. 4. Recompile every port, so all dependencies are the 6.0 libs. 1. and 2. are not an option if you plan on eventually compiling new ports after the upgrade - you will most certainly get mixed linkage, which will result in runtime errors. Compat5x should only be used for leaf-ports (i.e, applications and libraries which aren't linked to anything else) - for example software that is distributed as dynamically linked binaries only. Option 4 is certainly the safest thing to do (and you could just upgrade from binary packages instead of recompiling). -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgpdx8CqRe2PP.pgp Description: PGP signature
Re: Disk 100% busy
In the last episode (Oct 16), Will Saxon said: I am trying to diagnose a problem whereby a virus scanner (clam antivirus) is taking too long to scan attachments on a mail server. We have an attachment limitation of 20MB and an attachment of 7-20MB can take over 3 minutes to scan. This often causes the sending mail server to timeout and resend the mail. In this case, my mail gateway is is a dual 3.06GHz Xeon with 1GB of ram and 2 36GB 15krpm drives in a raid-1 on a smart array 6i (cciss) controller. I am running FreeBSD 5.4-RELEASE-p1. Systat -vmstat reports the disk mirror is 100% busy at all times on this machine, with an average of around 300 tps at 15KB/t. This seems wrong to me, as these numbers are maintained even when the system doesn't otherwise appear busy. We don't seem to be swamped by log writes. How can I tell what's generating these disk writes? At the moment the 100% disk utilization is the only thing I can see that would cause the scanning delay. The machine overall is sluggish with file operations. Are you swapping? Check either vmstat 1 or top output. You can also tell top to display blocking I/O requests per process by hitting m, then ask it to sort by I/O by hitting ototalenter. -- Dan Nelson [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: Disk 100% busy
At 9:16 AM -0400 2005-10-16, Will Saxon wrote: In this case, my mail gateway is is a dual 3.06GHz Xeon with 1GB of ram and 2 36GB 15krpm drives in a raid-1 on a smart array 6i (cciss) controller. I am running FreeBSD 5.4-RELEASE-p1. Systat -vmstat reports the disk mirror is 100% busy at all times on this machine, with an average of around 300 tps at 15KB/t. Note that RAID-1 is the second worst-case for mail server performance -- it accelerates reads (if you have mirror load-balancing), but all writes are required to be held until complete on both disks. The only worse case would be RAID-5, where you have to write (or re-write) an entire RAID block at once, plus the parity information. For mail servers, you really want to watch your synchronous meta-data updates. FreeBSD is a good choice here, if you've got Soft Updates enabled (I think that FreeBSD 5.x does that by default). But, you also want to watch your directory sizes. If the directory size gets too large, then it takes too long to lock the directory against any other updates, scan through the entire directory to make sure there aren't any collisions, create/delete the file, then unlock the directory -- a process which has to be done every time a file is created or deleted. This is why most modern mail servers use a hashed queue scheme, so that you can greatly increase the chances of multiple processes working simultaneously without stepping all over each others toes. However, with regards to directory size issues, keep in mind that even if the directory does not currently have 100,000 files in it, if it ever had 100k files in it in the past, it's still got all those empty directory slots laying around and that still slows things down a lot. If you suspect that this may have happened in the past, you need to stop the offending program, move the old directories aside, create new directories with the same ownership/permissions, then restart the program. And don't forget to make sure to clean out the old directories you had moved aside, either by creating some manual queue runners, or whatever. In your case, while the MTA may be configured in a way to avoid most of these issues, the anti-virus scanning solution may not. So, you may need to find a way to go in and deal with this. If you want to find out how all these issues affect the MTA, you need to read the book sendmail Performance Tuning by Nick Christenson (see http://www.jetcafe.org/npc/book/sendmail/). Once you read this book, you will hopefully have a better idea of how these same issues may affect your anti-virus scanning solution, and what you may need to do about it. I also recommend the slides from Nick's Performance Tuning Sendmail Systems paper at http://www.jetcafe.org/npc/doc/performance_tuning.pdf, as well as my own slides on the same general subject at http://www.shub-internet.org/brad/papers/sendmail-tuning/. This seems wrong to me, as these numbers are maintained even when the system doesn't otherwise appear busy. We don't seem to be swamped by log writes. How can you be sure? How are you logging information today? Is that being logged to a separate filesystem on a separate disk system? How can I tell what's generating these disk writes? At the moment the 100% disk utilization is the only thing I can see that would cause the scanning delay. The machine overall is sluggish with file operations. You have a certain amount of information available to you from tools like vmstat and iostat, as well as systat. However, in order to understand how to use them to see where your problems really lie, you need information such as provided in Nick's book. You should also read other books on overall system performance tuning. The O'Reilly book on this subject (see http://www.oreilly.com/catalog/spt2/) is a good start, even though it is a few years old. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See http://www.sage.org/ for more info. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Voodoo with md(4) panics system reliably
Hello,
I'm attempting to simulate unionfs on RELENG_5_4 by remounting
multiple times one vnode-backed md disk and then union mounting
others on top. Here are my steps below w/ a quick backtrace. I
have the core saved and can look into it farther if need be.
Ideas outside of ``don't do that''?
Jon
touch /root/foo
mdconfig -a -t vnode -s 32m -f /root/foo
newfs /dev/md0
mount /dev/md0 /tmp/md0
touch /tmp/md0/test1
umount /tmp/md0
mdconfig -d -u md0
# Strangeness coming
mdconfig -a -t vnode -f /root/foo -o readonly -u md0
mdconfig -a -t vnode -f /root/foo -o readonly -u md1
mdconfig -a -t vnode -f /root/foo -o readonly -u md2
mount -o ro /dev/md0 /tmp/md0
mount -o ro /dev/md1 /tmp/md1
mount -o ro /dev/md1 /tmp/md2
# Multiple mounts
touch bar{0,1,2}
mdconfig -a -t vnode -s 32m -f /root/bar0 -u md4
mdconfig -a -t vnode -s 32m -f /root/bar1 -u md5
mdconfig -a -t vnode -s 32m -f /root/bar2 -u md6
newfs /dev/md4
newfs /dev/md5
newfs /dev/md6
mount -o union /dev/md4 /tmp/md0
mount -o union /dev/md5 /tmp/md1
mount -o union /dev/md6 /tmp/md2
mount
[snip]
/dev/md0 on /tmp/md0 (ufs, local, read-only)
/dev/md1 on /tmp/md1 (ufs, local, read-only)
/dev/md2 on /tmp/md2 (ufs, local, read-only)
/dev/md4 on /tmp/md0 (ufs, local, union)
/dev/md5 on /tmp/md1 (ufs, local, union)
/dev/md6 on /tmp/md2 (ufs, local, union)
mdconfig -l
md6 md5 md4 md2 md1 md0
ls -li /tmp/md0
total 2
3 drwxrwxr-x 2 root operator 512 Oct 16 20:30 .snap
4 -rw-r--r-- 1 root wheel 0 Oct 16 20:21 test1
touch /tmp/md0/test2
ls -li /tmp/md0
total 2
3 drwxrwxr-x 2 root operator 512 Oct 16 20:30 .snap
4 -rw-r--r-- 1 root wheel 0 Oct 16 20:21 test1
4 -rw-r--r-- 1 root wheel 0 Oct 16 20:31 test2
touch /tmp/md0/test3
ls -li /tmp/md0
total 2
3 drwxrwxr-x 2 root operator 512 Oct 16 20:30 .snap
4 -rw-r--r-- 1 root wheel 0 Oct 16 20:21 test1
4 -rw-r--r-- 1 root wheel 0 Oct 16 20:31 test2
5 -rw-r--r-- 1 root wheel 0 Oct 16 20:32 test3
panic
(kgdb) bt
#0 doadump () at pcpu.h:159
#1 0xc054d2e2 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:410
#2 0xc054d578 in panic (fmt=0xc0735a98 ffs_sync: rofs mod)
at /usr/src/sys/kern/kern_shutdown.c:566
#3 0xc068a5fc in ffs_sync (mp=0xc2304000, waitfor=3,
cred=0xc21dbd80,
td=0xc22efd80) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1123
#4 0xc05a23b6 in sync_fsync (ap=0xe49f2ce4)
at /usr/src/sys/kern/vfs_subr.c:3475
#5 0xc059f1cd in sched_sync () at vnode_if.h:627
#6 0xc0538e88 in fork_exit (callout=0xc059ee0c sched_sync,
arg=0x0,
frame=0xe49f2d48) at /usr/src/sys/kern/kern_fork.c:791
#7 0xc06d43bc in fork_trampoline () at
/usr/src/sys/i386/i386/exception.s:209
(kgdb) f 3
#3 0xc068a5fc in ffs_sync (mp=0xc2304000, waitfor=3,
cred=0xc21dbd80,
td=0xc22efd80) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1123
1123lockreq = LK_EXCLUSIVE | LK_NOWAIT;
(kgdb) inf f
Stack level 3, frame at 0xe49f2c94:
eip = 0xc068a5fc in ffs_sync
(/usr/src/sys/ufs/ffs/ffs_vfsops.c:1123);
saved eip 0xc05a23b6
called by frame at 0xe49f2cc4, caller of frame at 0xe49f2c3c
source language c.
Arglist at 0xe49f2c38, args: mp=0xc2304000, waitfor=3,
cred=0xc21dbd80,
td=0xc22efd80
Locals at 0xe49f2c38, Previous frame's sp is 0xe49f2c94
Saved registers:
ebx at 0xe49f2c80, ebp at 0xe49f2c8c, esi at 0xe49f2c84, edi at
0xe49f2c88,
eip at 0xe49f2c90
(kgdb) l
1118}
1119/*
1120 * Write back each (modified) inode.
1121 */
1122wait = 0;
1123lockreq = LK_EXCLUSIVE | LK_NOWAIT;
1124if (waitfor == MNT_WAIT) {
1125wait = 1;
1126lockreq = LK_EXCLUSIVE;
1127}
__
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
