Email Address Update
Hello, I have discontinued using the email address your message was sent to. Please update your address book with my current email address; [EMAIL PROTECTED] and resend any messages that received this reply. Thank you. Warren Mosler, Valance Co. Inc. 5000 Estate Southgate, Christiansted, USVI 00820 340-692-7710, [EMAIL PROTECTED], www.mosler.org Associate Fellow, Cambridge Centre for Economic and Public Policy Dept. of Land Economy, University of Cambridge, Cambridge, UK ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
pear
Hi everybody: I have a problem with pear: Last week I tried to upgrade pear-XML_RPC but all that I got was this error: /usr/ports/lang/php5/work/php-5.0.4/Zend/zend_hash.c(678) : ht=0x8182570 is already destroyed /usr/ports/lang/php5/work/php-5.0.4/Zend/zend_hash.c(678) : ht=0x8182570 is already destroyed /usr/ports/lang/php5/work/php-5.0.4/Zend/zend_hash.c(67) : Bailed out without a bailout address! After this the upgrade tried to come back to the old version but I got the same error. Now the pear_XML_RPC package is no more installed. I get the same lines if I use pear with every command (e.g pear info package): morannon# pear Commands: build Build an Extension From C Source bundle Unpacks a Pecl Package clear-cacheClear XML-RPC Cache . . . upgradeUpgrade Package upgrade-allUpgrade All Packages Usage: pear [options] command [command-options] parameters Type pear help options to list all options. Type pear help shortcuts to list all command shortcuts. Type pear help command to get the help for the specified command. /usr/ports/lang/php5/work/php-5.0.4/Zend/zend_hash.c(678) : ht=0x8182570 is already destroyed /usr/ports/lang/php5/work/php-5.0.4/Zend/zend_hash.c(678) : ht=0x8182570 is already destroyed /usr/ports/lang/php5/work/php-5.0.4/Zend/zend_hash.c(67) : Bailed out without a bailout address! so it's also impossible to use pear upgrade What should I do? Thank You all. Riccardo ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Today's RELENG_5_4 and 'lock cmpxchgl'
On Thu, Jul 14, 2005 at 01:44:04PM -0400, Kris Kennaway wrote: The -CURRENT traces are very different from these, but I don't have comconsole on the -CURRENT machine. Thanks. Since I get plenty of opportunities to fiddle in the debugger now, because this happens a lot (we use screen a lot), tell me if anyone needs any specific info from the debugger prompt. Am I really the only one seeing this ? Or has someone been able to reproduce it yet ? Anyway, if people are having problems reproducing this, I'd like to know. I don't have a single RELENG_5 or 6 machine that withstands the 'screen-test'... This will hopefully be very useful in investigating and developing a fix for the problem, at least on 6.0 (others have speculated that the problem may be too difficult to fix in the 5.x branch). That sounds too scary to go into. Besides: it has worked on older FreeBSD 5.x systems... Perhaps 'others' could 'speculate' on list, so we might know why they're thinking that ? :-P Should SMP machines revert to FreeBSD 4.x in the mean time ? :-( Marc pgpHjgTVgBchD.pgp Description: PGP signature
Re: Today's RELENG_5_4 and 'lock cmpxchgl'
On Fri, Jul 15, 2005 at 11:40:27AM +0200, Marc Olzheim wrote: On Thu, Jul 14, 2005 at 01:44:04PM -0400, Kris Kennaway wrote: The -CURRENT traces are very different from these, but I don't have comconsole on the -CURRENT machine. Thanks. Am I really the only one seeing this ? Or has someone been able to reproduce it yet ? Ok, even non-SMP 7-CURRENT crashes on it, so I do not believe that I'm the only one seeing this... Marc pgpHFOtvMXyXd.pgp Description: PGP signature
reducing shutdown time (was: Re: dangerous situation with shutdown process)
Am Freitag, den 15.07.2005, 11:15 +0600 schrieb Sergey N. Voronkov: On Thu, Jul 14, 2005 at 04:17:06PM -0400, asym wrote: At 15:19 7/14/2005, Wilko Bulte wrote: On Thu, Jul 14, 2005 at 12:14:49PM -0700, Kevin Oberman wrote.. Date: Thu, 14 Jul 2005 20:38:15 +0200 From: Anatoliy Dmytriyev [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] [...] If you can't increase shutdown timeout, decrease softupdates timers. # tail -3 /etc/sysctl.conf kern.metadelay=14 kern.dirdelay=15 kern.filedelay=17 That was my solution for shutdown wait timeout. Intersting, I didn't know these knobs. Would it be okay to set them to zero on an embedded system with r/o file systems? And are there other variables tunable for reducing shutdown time (on 4-STABLE)? TIA, Marc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 6.0-BETA1 Available
Announcement The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 6.0-BETA1, which marks the beginning of the FreeBSD 6.0 Release Cycle. FreeBSD 6.0 will be a much less dramatic step from the FreeBSD 5 branch than the FreeBSD 5 branch was from FreeBSD 4. Much of the work that has gone into 6.0 development has focused on polishing and improving the work from 5.x These changes include streamlining direct device access in the kernel, providing a multi-threaded SMP-safe UFS/VFS filesystem layer, implementing WPA and Host-AP 802.11 features, as well as countless bugfixes and device driver improvements. Major updates and improvements have been made to ACPI power and thermal management, ATA, and many aspects of the network infrastructure. 32bit application support for AMD64 is also greatly improved, as is compatiblity with certain Athlon64 motherboards. This release is also the first to feature experimental PowerPC support for the Macintosh G3 and G4 platforms. This BETA1 release is in the same basic format as the Monthly Snapshots. For most of the architectures only the ISO images are available though the FTP install tree is available for a couple of the architectures. We encourage people to help with testing so any final bugs can be identified and worked out. Availability of ISO images is given below. If you have an older system you want to update using the normal CVS/cvsup source based upgrade the branch tag to use is RELENG_6 (though that will change for the Release Candidates later). Problem reports can be submitted using the send-pr(1) command. The list of open issues and things still being worked on are on the todo list: http://www.freebsd.org/releases/6.0R/todo.html Since this is the first release of a new branch we only have a rough idea for some of the dates. The current rough schedule is available but most dates are still listed as TBD - To Be Determined: http://www.freebsd.org/releases/6.0R/schedule.html Known Issues For the PowerPC architecture /etc/fstab isn't written out properly, so the first boot throws you into the mountroot prompt. You will need to manually enter where the root partition is and fix /etc/fstab. Also the GEM driver is listed as 'unknown' in the network config dialog. For all architectures a kernel rebuild might be needed to get some FreeBSD 5 applications to run. Add options COMPAT_FREEBSD5 to the kernel configuration file if you have problems with FreeBSD 5 executables. Availability The BETA1 ISOs and FTP support are available on most of the FreeBSD Mirror sites. A list of the mirror sites is available here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors-ftp.html The MD5s are: MD5 (6.0-BETA1-alpha-bootonly.iso) = eabda0a086e5492fe43626ce5be1d7e1 MD5 (6.0-BETA1-alpha-disc1.iso) = d7fe900bb3d5f259cc3cc565c4f303e4 MD5 (6.0-BETA1-amd64-bootonly.iso) = 9b04cb2f68300071c717f4aa4220bdac MD5 (6.0-BETA1-amd64-disc1.iso) = cb0f21feaf8b7dd9621f82a8157f6ed8 MD5 (6.0-BETA1-amd64-disc2.iso) = 84d40bc291a9ed5cd69dfa717445eeb5 MD5 (6.0-BETA1-i386-bootonly.iso) = 38e0b202ee7d279bae002b883f7074ec MD5 (6.0-BETA1-i386-disc1.iso) = b2baa8c18d4637ef02822a0da6717408 MD5 (6.0-BETA1-i386-disc2.iso) = 2b151a3cea8843d322c75ff76779ffcf MD5 (6.0-BETA1-ia64-bootonly.iso) = 97800ec7d4b29927a8e66a2b53e987fb MD5 (6.0-BETA1-ia64-disc1.iso) = 7d29cd9317997136507078971762a0d8 MD5 (6.0-BETA1-ia64-livefs.iso) = 6ff974e60a3964cf16fcec05925c14e9 MD5 (6.0-BETA1-pc98-disc1.iso) = 40a3134cce89bd5f7033d8b9181edf91 MD5 (6.0-BETA1-powerpc-bootonly.iso) = 2f64974e9bd5adcf813f5d35ff742443 MD5 (6.0-BETA1-powerpc-disc1.iso) = b2562c38414ff4866f5ed8b3a38683c8 MD5 (6.0-BETA1-sparc64-bootonly.iso) = ae9610aeb1169d2cc649628606014441 MD5 (6.0-BETA1-sparc64-disc1.iso) = af21752630b13cf60c9498fbf7f793b6 MD5 (6.0-BETA1-sparc64-disc2.iso) = 3241af814bfe93a97707c7a964c57718 Thanks to Ken Smith, Marcel Moolenaar, Wilko Bulte, and Takahashi Yoshihiro, and Peter Grehan for doing the sparc64, ia64, alpha, pc98, and ppc builds, respectively. Thanks also to Ken Smith for his help on writing much of this announcement. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: reducing shutdown time
Marc Santhoff wrote: Am Freitag, den 15.07.2005, 11:15 +0600 schrieb Sergey N. Voronkov: Intersting, I didn't know these knobs. Would it be okay to set them to zero on an embedded system with r/o file systems? On embeded system with r/o filesystems you may just turn softupdates off. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: reducing shutdown time
Am Freitag, den 15.07.2005, 15:10 +0400 schrieb Igor Robul: Marc Santhoff wrote: Am Freitag, den 15.07.2005, 11:15 +0600 schrieb Sergey N. Voronkov: Intersting, I didn't know these knobs. Would it be okay to set them to zero on an embedded system with r/o file systems? On embeded system with r/o filesystems you may just turn softupdates off. So those vars are only applicant for softupdates. No, no softupdates involved. I was searching for a way to shorten the stopping time in general. Thank you anyways, Marc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Today's RELENG_5_4 and 'lock cmpxchgl'
On Fri, Jul 15, 2005 at 12:05:39PM +0200, Marc Olzheim wrote: On Fri, Jul 15, 2005 at 11:40:27AM +0200, Marc Olzheim wrote: On Thu, Jul 14, 2005 at 01:44:04PM -0400, Kris Kennaway wrote: The -CURRENT traces are very different from these, but I don't have comconsole on the -CURRENT machine. Thanks. Am I really the only one seeing this ? Or has someone been able to reproduce it yet ? Ok, even non-SMP 7-CURRENT crashes on it, so I do not believe that I'm the only one seeing this... You're not..as noted, it's been widely reported. Kris pgpITXOSpPCSz.pgp Description: PGP signature
Subscribe request result (mule ML)
Hi, I am the fml mailing list manager for [EMAIL PROTECTED]. Hmm, you may be not a member. 1. Your mail may come from a bad address which is not registered in this mailing list 2. Your mail has a syntax error. If you would like to subscribe this mailing list subscribe YOUR NAME For example subscribe Hayakawa Aoi Hi, I am the fml ML manager for the ML [EMAIL PROTECTED]. [EMAIL PROTECTED], Be Seeing You! If you have any questions or problems, please contact [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
mpt + gvinum on 6.0-BETA
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I tried 6.0-BETA on one of our FUJITSU-SIEMENS RX300 S2 servers and it seems that I have problems with the disk subsystem, even after Scotts major overhaul of the mpt drivers... I'm not able to post detailed dmesg output in the moment (IMHO there isn't anything to notice, mpt0 and mpt1 are attached without any errors) but the symtoms are: - - very slow write performace: 'dd if=/dev/zero of=/dev/da0s2 bs=512 count=32768' reports a throughput of 80 k(!)Bytes/s. Read performance is somewhat better, 'dd' reports here about 2 MB/s... better, but not what I would expect from a RAID1 with two U320 SCSI-disks (Seagate BTW). - - 'gvinum' has its problems too with this RAID Volume: I *can* create a gvinum-drive on /dev/da0s2, but it remains 'down'. I can't 'start' it and after a reboot, the gvinum-drive has gone and gvinum is absolutely clean again. This seems not to be a problem of gvinum, as it works perfectly under 6.0-BETA on my personal machine (Athlon-XP 2000, ahc-controller, FUJITSU SCSI disk). Still to mention: The RX300 has two Xeon CPUs and 2Gig RAM. It runs with a stripped down kernel, based on GENERIC *without* all that WITTNESS and INVARIANTS stuff. /etc/malloc.conf is linked to 'aj' - that's all that I know of debugging options in CURRENT kernels... The questions I have: The LSI 1040 RAID-Controller is absolutely new to me, I did configure a RAID1 Volume, synchronized it and that's all. Is there anything to tweak besides the default config of that controller? What additional informations do you need? I should be able to supply them on monday... But there's not too much time to test, this machine should become a Windoze printserver in about two or three weeks... It seems to me that the HP DL380 is still the better machine... :-/ - -- Ciao/BSD - Matthias Matthias Schuendehuettemsch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFC174af1BNcN37Cl8RAtvcAKCDwcuIA7XusCCX80N6b4LmN0JRKwCfbvA+ VSfudFkdO3UHmOqpVR18obU= =Vzw8 -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: FreeBSD 6.0-BETA1 Available
And, for the stupid question of the day ... how long before 5.x is no longer supported? I'm just about to deploy a new server, and was *going* to go with 5.x, but would I be better just skipping 5.x altogether? Or are there such drastic changes in 6.x that doing so at this time wouldn't be prudent? On Fri, 15 Jul 2005, Scott Long wrote: Announcement The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 6.0-BETA1, which marks the beginning of the FreeBSD 6.0 Release Cycle. FreeBSD 6.0 will be a much less dramatic step from the FreeBSD 5 branch than the FreeBSD 5 branch was from FreeBSD 4. Much of the work that has gone into 6.0 development has focused on polishing and improving the work from 5.x These changes include streamlining direct device access in the kernel, providing a multi-threaded SMP-safe UFS/VFS filesystem layer, implementing WPA and Host-AP 802.11 features, as well as countless bugfixes and device driver improvements. Major updates and improvements have been made to ACPI power and thermal management, ATA, and many aspects of the network infrastructure. 32bit application support for AMD64 is also greatly improved, as is compatiblity with certain Athlon64 motherboards. This release is also the first to feature experimental PowerPC support for the Macintosh G3 and G4 platforms. This BETA1 release is in the same basic format as the Monthly Snapshots. For most of the architectures only the ISO images are available though the FTP install tree is available for a couple of the architectures. We encourage people to help with testing so any final bugs can be identified and worked out. Availability of ISO images is given below. If you have an older system you want to update using the normal CVS/cvsup source based upgrade the branch tag to use is RELENG_6 (though that will change for the Release Candidates later). Problem reports can be submitted using the send-pr(1) command. The list of open issues and things still being worked on are on the todo list: http://www.freebsd.org/releases/6.0R/todo.html Since this is the first release of a new branch we only have a rough idea for some of the dates. The current rough schedule is available but most dates are still listed as TBD - To Be Determined: http://www.freebsd.org/releases/6.0R/schedule.html Known Issues For the PowerPC architecture /etc/fstab isn't written out properly, so the first boot throws you into the mountroot prompt. You will need to manually enter where the root partition is and fix /etc/fstab. Also the GEM driver is listed as 'unknown' in the network config dialog. For all architectures a kernel rebuild might be needed to get some FreeBSD 5 applications to run. Add options COMPAT_FREEBSD5 to the kernel configuration file if you have problems with FreeBSD 5 executables. Availability The BETA1 ISOs and FTP support are available on most of the FreeBSD Mirror sites. A list of the mirror sites is available here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors-ftp.html The MD5s are: MD5 (6.0-BETA1-alpha-bootonly.iso) = eabda0a086e5492fe43626ce5be1d7e1 MD5 (6.0-BETA1-alpha-disc1.iso) = d7fe900bb3d5f259cc3cc565c4f303e4 MD5 (6.0-BETA1-amd64-bootonly.iso) = 9b04cb2f68300071c717f4aa4220bdac MD5 (6.0-BETA1-amd64-disc1.iso) = cb0f21feaf8b7dd9621f82a8157f6ed8 MD5 (6.0-BETA1-amd64-disc2.iso) = 84d40bc291a9ed5cd69dfa717445eeb5 MD5 (6.0-BETA1-i386-bootonly.iso) = 38e0b202ee7d279bae002b883f7074ec MD5 (6.0-BETA1-i386-disc1.iso) = b2baa8c18d4637ef02822a0da6717408 MD5 (6.0-BETA1-i386-disc2.iso) = 2b151a3cea8843d322c75ff76779ffcf MD5 (6.0-BETA1-ia64-bootonly.iso) = 97800ec7d4b29927a8e66a2b53e987fb MD5 (6.0-BETA1-ia64-disc1.iso) = 7d29cd9317997136507078971762a0d8 MD5 (6.0-BETA1-ia64-livefs.iso) = 6ff974e60a3964cf16fcec05925c14e9 MD5 (6.0-BETA1-pc98-disc1.iso) = 40a3134cce89bd5f7033d8b9181edf91 MD5 (6.0-BETA1-powerpc-bootonly.iso) = 2f64974e9bd5adcf813f5d35ff742443 MD5 (6.0-BETA1-powerpc-disc1.iso) = b2562c38414ff4866f5ed8b3a38683c8 MD5 (6.0-BETA1-sparc64-bootonly.iso) = ae9610aeb1169d2cc649628606014441 MD5 (6.0-BETA1-sparc64-disc1.iso) = af21752630b13cf60c9498fbf7f793b6 MD5 (6.0-BETA1-sparc64-disc2.iso) = 3241af814bfe93a97707c7a964c57718 Thanks to Ken Smith, Marcel Moolenaar, Wilko Bulte, and Takahashi Yoshihiro, and Peter Grehan for doing the sparc64, ia64, alpha, pc98, and ppc builds, respectively. Thanks also to Ken Smith for his help on writing much of this announcement. -- This mail is for the internal use of the FreeBSD project committers, and as such is private. This mail may not be published or forwarded outside the FreeBSD committers' group or disclosed to other unauthorised parties without the explicit permission of the author(s). Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
Re: dangerous situation with shutdown process
On Thu, Jul 14, 2005 at 22:31 , [EMAIL PROTECTED] moved his mouse, rebooted for the change to take effect, and then said: Message: 13 Date: Thu, 14 Jul 2005 20:38:15 +0200 From: Anatoliy Dmytriyev [EMAIL PROTECTED] Subject: dangerous situation with shutdown process To: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=UTF-8; format=flowed Hello, everybody! I have found unusual and dangerous situation with shutdown process: I did a copy of 200 GB data on the 870 GB partition (softupdates is enabled) by cp command. It took a lot of time when I did umount for this partition exactly after cp, but procedure finished correctly. In case, if I did ???shutdown ???h(r)???, also exactly after cp, the shutdown procedure waited for ???sync??? (umounting of the file system) but sync process was terminated by timeout, and fsck checked and did correction of the file system after boot. System 5.4-stable, RAM 4GB, processor P-IV 3GHz. How can I fix it on my system? Copying very large files and then shutting down I hope is not a normal procecure for you. softupdates sometimes do take a long time when you are removing/copying very large files. Others have suggested different time-outs but you'd have to figure out the largest size you may every encounter and set things for that, which is not going to help for everyday operation. I've watched the amount of disk space increase slowly by performing 'df' and it can take a long time - up to a minute on some extremely large partitions I was cleaning. One way to force everything to be written I've found [by observation only] is to perform an fsck on that file system. If you only do huge copies and immediate shutdowns rarely, then maybe it's just a good idea to remember how softupdates work, and then fsck, then shutdown. I'm always against changing default operations from typical operations to extremes. Bill -- Bill Vermillion - bv @ wjv . com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0-BETA1 Available
Am Freitag, 15. Juli 2005 16:58 CEST schrieb Marc G. Fournier: And, for the stupid question of the day ... how long before 5.x is no longer supported? I'm just about to deploy a new server, and was *going* to go with 5.x, but would I be better just skipping 5.x altogether? Or are there such drastic changes in 6.x that doing so at this time wouldn't be prudent? To post my opinion to the last part of the question: I'm also deploying new servers and I'll take RELENG_6 since there are so many improovements (nullfs in jails etc.) and 6-current has been pretty stable for me on my UP workstation with all kinds of new stuff enabled (ULE PREEMPTION), so I guess I won't see more troubles than with 5.4, I think less :) -Harry On Fri, 15 Jul 2005, Scott Long wrote: Announcement The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 6.0-BETA1, which marks the beginning of the FreeBSD 6.0 Release Cycle. FreeBSD 6.0 will be a much less dramatic step from the FreeBSD 5 branch than the FreeBSD 5 branch was from FreeBSD 4. Much of the work that has gone into 6.0 development has focused on polishing and improving the work from 5.x These changes include streamlining direct device access in the kernel, providing a multi-threaded SMP-safe UFS/VFS filesystem layer, implementing WPA and Host-AP 802.11 features, as well as countless bugfixes and device driver improvements. Major updates and improvements have been made to ACPI power and thermal management, ATA, and many aspects of the network infrastructure. 32bit application support for AMD64 is also greatly improved, as is compatiblity with certain Athlon64 motherboards. This release is also the first to feature experimental PowerPC support for the Macintosh G3 and G4 platforms. This BETA1 release is in the same basic format as the Monthly Snapshots. For most of the architectures only the ISO images are available though the FTP install tree is available for a couple of the architectures. We encourage people to help with testing so any final bugs can be identified and worked out. Availability of ISO images is given below. If you have an older system you want to update using the normal CVS/cvsup source based upgrade the branch tag to use is RELENG_6 (though that will change for the Release Candidates later). Problem reports can be submitted using the send-pr(1) command. The list of open issues and things still being worked on are on the todo list: http://www.freebsd.org/releases/6.0R/todo.html Since this is the first release of a new branch we only have a rough idea for some of the dates. The current rough schedule is available but most dates are still listed as TBD - To Be Determined: http://www.freebsd.org/releases/6.0R/schedule.html Known Issues For the PowerPC architecture /etc/fstab isn't written out properly, so the first boot throws you into the mountroot prompt. You will need to manually enter where the root partition is and fix /etc/fstab. Also the GEM driver is listed as 'unknown' in the network config dialog. For all architectures a kernel rebuild might be needed to get some FreeBSD 5 applications to run. Add options COMPAT_FREEBSD5 to the kernel configuration file if you have problems with FreeBSD 5 executables. Availability The BETA1 ISOs and FTP support are available on most of the FreeBSD Mirror sites. A list of the mirror sites is available here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors-ftp. html The MD5s are: MD5 (6.0-BETA1-alpha-bootonly.iso) = eabda0a086e5492fe43626ce5be1d7e1 MD5 (6.0-BETA1-alpha-disc1.iso) = d7fe900bb3d5f259cc3cc565c4f303e4 MD5 (6.0-BETA1-amd64-bootonly.iso) = 9b04cb2f68300071c717f4aa4220bdac MD5 (6.0-BETA1-amd64-disc1.iso) = cb0f21feaf8b7dd9621f82a8157f6ed8 MD5 (6.0-BETA1-amd64-disc2.iso) = 84d40bc291a9ed5cd69dfa717445eeb5 MD5 (6.0-BETA1-i386-bootonly.iso) = 38e0b202ee7d279bae002b883f7074ec MD5 (6.0-BETA1-i386-disc1.iso) = b2baa8c18d4637ef02822a0da6717408 MD5 (6.0-BETA1-i386-disc2.iso) = 2b151a3cea8843d322c75ff76779ffcf MD5 (6.0-BETA1-ia64-bootonly.iso) = 97800ec7d4b29927a8e66a2b53e987fb MD5 (6.0-BETA1-ia64-disc1.iso) = 7d29cd9317997136507078971762a0d8 MD5 (6.0-BETA1-ia64-livefs.iso) = 6ff974e60a3964cf16fcec05925c14e9 MD5 (6.0-BETA1-pc98-disc1.iso) = 40a3134cce89bd5f7033d8b9181edf91 MD5 (6.0-BETA1-powerpc-bootonly.iso) = 2f64974e9bd5adcf813f5d35ff742443 MD5 (6.0-BETA1-powerpc-disc1.iso) = b2562c38414ff4866f5ed8b3a38683c8 MD5 (6.0-BETA1-sparc64-bootonly.iso) = ae9610aeb1169d2cc649628606014441 MD5 (6.0-BETA1-sparc64-disc1.iso) = af21752630b13cf60c9498fbf7f793b6 MD5 (6.0-BETA1-sparc64-disc2.iso) = 3241af814bfe93a97707c7a964c57718 Thanks to Ken Smith, Marcel Moolenaar, Wilko Bulte, and Takahashi Yoshihiro, and Peter
Re: FreeBSD 6.0-BETA1 Available
Marc G. Fournier wrote: And, for the stupid question of the day ... how long before 5.x is no longer supported? The FreeBSD Security Team will support FreeBSD 5.x until at least the end of September 2007. Support from other teams and the ports tree may end sooner, but since there aren't very large differences between 5.x and 6.x I doubt there will be many problems. I'm just about to deploy a new server, and was *going* to go with 5.x, but would I be better just skipping 5.x altogether? Or are there such drastic changes in 6.x that doing so at this time wouldn't be prudent? If I was deploying a new server today, I'd install FreeBSD 5.4. If I were planning on installing a new server next month, I'd install FreeBSD 6.0-BETA-whatever-number-we're-up-to-by-then. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0-BETA1 Available
Marc G. Fournier wrote: And, for the stupid question of the day ... how long before 5.x is no longer supported? I'm just about to deploy a new server, and was *going* to go with 5.x, but would I be better just skipping 5.x altogether? Or are there such drastic changes in 6.x that doing so at this time wouldn't be prudent? There will be a 5.5 release this fall and possibly a 5.6 a few months after that. Per the standard procedure, the security team will support the branch for 2 years after the final release. There will likely be other developers who have an interest in backporting changes to RELENG_5 for some time to come, just as has been done with RELENG_4. So the earliest that RELENG_5 will be de-supported is late 2007. However Part of the purpose of moving quickly on to RELENG_6 is so that the migration work for users from 5.x to 6.x is very small. 6.x is really just an evolutionary step from 5.x, not the life-altering revolutionary step that 4.x-5.x was. It should be quite easy to deploy and maintain 5.x and 6.x machines side-by-side and migrate them as the need arises. We don't want people to be stranded on RELENG_5 like they were with RELENG_4. 6.x offers everything of 5.x, but with better performance and (hopefully) better stability. If you're thinking about evaluating 5.x, give 6.0 a try also. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0-BETA1 Available
Quoth Scott Long on Fri, Jul 15, 2005 at 09:18:50 -0600 Part of the purpose of moving quickly on to RELENG_6 is so that the migration work for users from 5.x to 6.x is very small. 6.x is really just an evolutionary step from 5.x, not the life-altering revolutionary step that 4.x-5.x was. It should be quite easy to deploy and maintain 5.x and 6.x machines side-by-side and migrate them as the need arises. We don't want people to be stranded on RELENG_5 like they were with RELENG_4. 6.x offers everything of 5.x, but with better performance and (hopefully) better stability. If you're thinking about evaluating 5.x, give 6.0 a try also. Does that mean that a cvsup with *default tag=RELENG_6 and a rebuilt of the world will work smoothly? Would it work at all? Is it even recommended? I suspect that re-compiling every port is a good idea after making the world in any case. -- [EMAIL PROTECTED] -=*=- www.kierun.org PGP: 009D 7287 C4A7 FD4F 1680 06E4 F751 7006 9DE2 6318 pgpDOMGuQyjfg.pgp Description: PGP signature
4.11-STABLE leaks vnodes worse then 4.x from Feb 13th ... ?
Recently, I started having problems with one of my newest servers ... figuring that it might have somethign to do with the fact that I went SATA for this one (all others are SCSI), I figured it might be a driver issue causing the problems, since everything else is the same as the other 5 servers on our network ... Today, I'm starting to wonder if I've been just looking at the most obvious cause, instead of looking deeper ... The problem that manifests itself is similar to the old 'ran out of vnode' issue I used to experience under 4.x ... the server would still run, be totally pingable, and you could even get the motd when you tried to ssh in, but you couldn't get a prompt, and all processes were hung ... I just upgraded the kernel on this machine (mercury) on the 13th of July, and its been running 1 day, 12 hrs now ... there is hardly anything running on this machine (10 jails), and vnode usage is: debug.numvnodes: 336460 - debug.freevnodes: 5275 - debug.vnlru_nowhere: 0 - vlruwt One of my older servers (neptune), running kernels from Feb 13th of this year, and with 81 jails running on it, is using up *significantly less* vnodes (uptime: 1 day, 10 hours): debug.numvnodes: 279710 - debug.freevnodes: 91442 - debug.vnlru_nowhere: 0 - vlruwt Now, compared to neptune, mercury isn't running anything special ... several apache 1 processes, postfix, cyrus-imapd and that's it ... neptune on the other hand, is running the full gambit ... aolserver, java, apache 1 and 2, postfix, etc ... So, I'm starting to think that the problem isn't hardware related, but the kernel itself ... the latest 4.11-STABLE kernel seems to have brought in new vnode leakage, or ... vnlru isn't working as it should be to free up vnodes ... Looking at that process on mercury: # ps aux | grep vnlru root7 0.0 0.0 00 ?? DL Wed11PM 0:00.65 (vnlru) whereas on neptune: # ps aux | grep vnlru root 9 0.0 0.0 00 ?? DL Thu01AM 0:00.79 (vnlru) so about the same about of CPU time being expended ... a bit more on the more loaded server, but not a major amount ... I'd like to try and debug this, but don't know where to start ... I realize that 4.x isn't being pushed anymore, but there are alot of us that haven't moved to 5.x yet (am working on that for our next server, but its going to take me several months before I can convert all our existing servers up) ... I do have a serial console on this server, if that helps to debug things ... I've heard that there was some work done on 5.x to clean up some of the vnode leaks ... not sure if that is fact or just rumor ... but, if so, would any of them be MFCable to 4.x? Thanks ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Read-only medium/device detection
Hi, when I mount a device (or medium) which is read-only without the -r option, I get lots of troubles when shutting down later. Syncer does not write all vnodes/blocks to disk. This happened to me with a write protected floppy disk (-t msdos) and a CD-R (-t ufs). It seems to me that read-only state of a file system is being initially setup according to the type of the file system. Wouldn't it be more appropriate to detect the medium/device capabilities to setup it read-only automatically if needed? Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0-BETA1 Available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Jul 15, 2005 at 04:27:44PM +0100, Yann Golanski wrote: Quoth Scott Long on Fri, Jul 15, 2005 at 09:18:50 -0600 Part of the purpose of moving quickly on to RELENG_6 is so that the migration work for users from 5.x to 6.x is very small. 6.x is really just an evolutionary step from 5.x, not the life-altering revolutionary step that 4.x-5.x was. It should be quite easy to deploy and maintain 5.x and 6.x machines side-by-side and migrate them as the need arises. We don't want people to be stranded on RELENG_5 like they were with RELENG_4. 6.x offers everything of 5.x, but with better performance and (hopefully) better stability. If you're thinking about evaluating 5.x, give 6.0 a try also. Does that mean that a cvsup with *default tag=RELENG_6 and a rebuilt of the world will work smoothly? Would it work at all? Is it even recommended? I did that without problem. There are some issues with libc.5.so and libc.6.so mostly (I think) having to do with perl. My only real issue was Japanese input, fixed by upgrading a few ports. Everything else seemed to work without trouble. - -- Scott GPG KeyID EB3467D6 ( 1B848 077D 66F6 9DB0 FDC2 A409 FA54 D575 EB34 67D6) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Xander: Oh. Okay. You and Willow go do the superpower thing, I'll stay behind and putt around the Batcave with crusty old Alfred here. Giles: Ah-ah, no. I am no Alfred, sir. No, you forget. Alfred had a job. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC19o2+lTVdes0Z9YRAmsKAKCHpED4gViYG9rBWVjH5Ro2Dj/pjwCfRmIa c9hZgRWzQ7eo+sKQGkskBC0= =/YhW -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: dangerous situation with shutdown process
Matthias Buelow wrote this message on Thu, Jul 14, 2005 at 21:52 +0200: The problem is that disks lie about whether they have actually written data. If the power goes off before the data is in cache, it's lost. No, the problem is that FreeBSD doesn't implement request barriers and that softupdates is flawed by design and seemingly could not make use of them, even if they were available (because, as I understand it, it relies on a total ordering of all writes, unlike the partial ordering necessary for a journalled fs). even request barries will not save the fs in a power loss if the track that is getting flushed durning a power loss... Some other FreeBSD folk has a reproducable case of where blocks that were not written to on ATA hardware got trashed after a power loss... With non-written to sectors getting trashed with the cache enabled, barriers don't mean squat... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
John-Mark Gurney wrote: With non-written to sectors getting trashed with the cache enabled, barriers don't mean squat... Of course if you pound the disk with a hammer, then barriers also won't help. Just because with a few disks perhaps it won't work at all doesn't mean that one shouldn't at least try and get it working for perhaps the 90% where it would work in order to reduce the possibility of corruption by as much as possible. I mean, anything is better than the current situation where apparently nothing is done at all. Why am I arguing in an uphill battle here? Is data safety no longer important to the FreeBSD community? Such issues should not even have to be discussed at all! mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
John-Mark Gurney wrote: even request barries will not save the fs in a power loss if the track that is getting flushed durning a power loss... Some other FreeBSD folk has a reproducable case of where blocks that were not written to on ATA hardware got trashed after a power loss... With non-written to sectors getting trashed with the cache enabled, barriers don't mean squat... One more thought.. they _do_ protect against power loss during writing a track -- when used in combination with a journalled fs. A corrupted journal can be detected. If it's corrupted, discard the whole thing, or only the relevant entry. The filesystem will remain consistent. If track corruption occurs after the journal is written, it doesn't matter, since at boot the journal will be replayed and all operations will be performed once more. The combination barriers+journal really seems to be very resilient to filesystem corruption. When it's implemented without errors, and the hardware doesn't do things like change bits randomly, I can't think of a way this scheme can be corrupted at all. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Matthias Buelow wrote: John-Mark Gurney wrote: [ ... ] Why am I arguing in an uphill battle here? Is data safety no longer important to the FreeBSD community? Such issues should not even have to be discussed at all! You ask a good question: so, just why are *you* arguing? [1] If sysctl hw.ata.wc=0 doesn't do what you want, please submit a PR containing something better. Or buy SCSI hardware and a real, battery-backed up RAID system, or fibre-channel, or Firewire, or whatever floats your boat. -- -Chuck [1]: After all, generally it takes at least two people to argue, although some people manage to argue even with themselves. :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0-BETA1 Available
While Scott's and Colin's responses should be viewed as canonical, for the record the place that the support matrix is documented is on the Security web page at http://www.freebsd.org/security/security.html#adv. Note that this only applies to the _security_ team. Traditionally the ports team has tried to keep everything going on at least those branches; however, in the near future this is going to start becoming more problematic, due to both the growth in the number of ports; the larger number of simultaneous -stable releases we are trying to support; and the fact that many developers have moved away from 4.X. (In particular, it is my understanding that the next release of GNOME due this fall is not going to be supported, by default, on 4.X; the next major release of KDE, due sometime later this year, will probably not be either. From this, it might be reasonable to conclude that the time that 4.X is viable for the desktop are drawing to a close.) Also to reiterate, the differences (at least for ports) between 5.X and 6.X is much smaller than for 4.X and 5.X; the difference between 6.X and 7.X is even smaller than that. Although I can't cite statistics in this case, my guess from reading the mailing lists is that most ports work is now being done on 5.X or 6.X and then only retrofitted to 4.X when demand warrants it. Finally, consider that if you want to upgrade from 4.X to 6.X without doing a complete reinstall, IIRC you will have to first upgrade to 5.X on the way in any case. Of course, whether or not one should do a complete reinstall between major versions _anyway_ is another discussion entirely. As a side-note, due to the size requirements in the FTP archives, it is becoming increasingly difficult to house packages for every supported release. Although there is no concrete decision yet, it seems likely that we will need to drop the 5.3-RELEASE packages and only archive packages for 5.4-RELEASE and 5-STABLE. If so, this will probably set a precedent for future releases (e.g. only having the latest release and latest snapshot for each major release). These are all things that people should take into account when trying to decide which release to upgrade to. My own view is that users who want to use packages are really going to be well-advised to be on either 5.4 or 6.0 pretty quickly; and that anyone who wishes to stay on 4.X for much longer should be prepared to increasingly provide their own ports support. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Chuck Swiger wrote: If sysctl hw.ata.wc=0 doesn't do what you want, please submit a PR containing something better. Or buy SCSI hardware and a real, Well, if I had the time, I would. Also if instead of softupdates, a proper journalled filesystem implementation with kernel support for write barriers in the block drivers had been implemented, we wouldn't have this problem now. Ok, no point in arguing how things would be if one had made different decisions in the past. battery-backed up RAID system, or fibre-channel, or Firewire, or whatever floats your boat. I would think that a significant part of (FreeBSD-) users are running FreeBSD on desktop PCs, notebooks, etc., where a fibre-channel or SCSI solution isn't really feasible (either technically, or economically). mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0-BETA1 Available
On Jul 15, 2005, at 5:10 PM, Emanuel Strobl wrote: Am Freitag, 15. Juli 2005 16:58 CEST schrieb Marc G. Fournier: And, for the stupid question of the day ... how long before 5.x is no longer supported? I'm just about to deploy a new server, and was *going* to go with 5.x, but would I be better just skipping 5.x altogether? Or are there such drastic changes in 6.x that doing so at this time wouldn't be prudent? To post my opinion to the last part of the question: I'm also deploying new servers and I'll take RELENG_6 since there are so many improovements (nullfs in jails etc.) and 6-current has been pretty stable for me on my Hoi, what's changed wrt jails? And nullfs? I haven't been following the news as closely as I perhaps should, but I feel that the jail functionality doesn't get half as much attention in release notes as it should... Porting my jail-related tools to 5.x from 4.x was painful, but enjoyable when I was done. How does 6.x look? /Eirik UP workstation with all kinds of new stuff enabled (ULE PREEMPTION), so I guess I won't see more troubles than with 5.4, I think less :) -Harry On Fri, 15 Jul 2005, Scott Long wrote: Announcement The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 6.0-BETA1, which marks the beginning of the FreeBSD 6.0 Release Cycle. FreeBSD 6.0 will be a much less dramatic step from the FreeBSD 5 branch than the FreeBSD 5 branch was from FreeBSD 4. Much of the work that has gone into 6.0 development has focused on polishing and improving the work from 5.x These changes include streamlining direct device access in the kernel, providing a multi-threaded SMP-safe UFS/VFS filesystem layer, implementing WPA and Host-AP 802.11 features, as well as countless bugfixes and device driver improvements. Major updates and improvements have been made to ACPI power and thermal management, ATA, and many aspects of the network infrastructure. 32bit application support for AMD64 is also greatly improved, as is compatiblity with certain Athlon64 motherboards. This release is also the first to feature experimental PowerPC support for the Macintosh G3 and G4 platforms. This BETA1 release is in the same basic format as the Monthly Snapshots. For most of the architectures only the ISO images are available though the FTP install tree is available for a couple of the architectures. We encourage people to help with testing so any final bugs can be identified and worked out. Availability of ISO images is given below. If you have an older system you want to update using the normal CVS/cvsup source based upgrade the branch tag to use is RELENG_6 (though that will change for the Release Candidates later). Problem reports can be submitted using the send-pr(1) command. The list of open issues and things still being worked on are on the todo list: http://www.freebsd.org/releases/6.0R/todo.html Since this is the first release of a new branch we only have a rough idea for some of the dates. The current rough schedule is available but most dates are still listed as TBD - To Be Determined: http://www.freebsd.org/releases/6.0R/schedule.html Known Issues For the PowerPC architecture /etc/fstab isn't written out properly, so the first boot throws you into the mountroot prompt. You will need to manually enter where the root partition is and fix /etc/fstab. Also the GEM driver is listed as 'unknown' in the network config dialog. For all architectures a kernel rebuild might be needed to get some FreeBSD 5 applications to run. Add options COMPAT_FREEBSD5 to the kernel configuration file if you have problems with FreeBSD 5 executables. Availability The BETA1 ISOs and FTP support are available on most of the FreeBSD Mirror sites. A list of the mirror sites is available here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors- ftp. html The MD5s are: MD5 (6.0-BETA1-alpha-bootonly.iso) = eabda0a086e5492fe43626ce5be1d7e1 MD5 (6.0-BETA1-alpha-disc1.iso) = d7fe900bb3d5f259cc3cc565c4f303e4 MD5 (6.0-BETA1-amd64-bootonly.iso) = 9b04cb2f68300071c717f4aa4220bdac MD5 (6.0-BETA1-amd64-disc1.iso) = cb0f21feaf8b7dd9621f82a8157f6ed8 MD5 (6.0-BETA1-amd64-disc2.iso) = 84d40bc291a9ed5cd69dfa717445eeb5 MD5 (6.0-BETA1-i386-bootonly.iso) = 38e0b202ee7d279bae002b883f7074ec MD5 (6.0-BETA1-i386-disc1.iso) = b2baa8c18d4637ef02822a0da6717408 MD5 (6.0-BETA1-i386-disc2.iso) = 2b151a3cea8843d322c75ff76779ffcf MD5 (6.0-BETA1-ia64-bootonly.iso) = 97800ec7d4b29927a8e66a2b53e987fb MD5 (6.0-BETA1-ia64-disc1.iso) = 7d29cd9317997136507078971762a0d8 MD5 (6.0-BETA1-ia64-livefs.iso) = 6ff974e60a3964cf16fcec05925c14e9 MD5 (6.0-BETA1-pc98-disc1.iso) = 40a3134cce89bd5f7033d8b9181edf91 MD5 (6.0-BETA1-powerpc-bootonly.iso) = 2f64974e9bd5adcf813f5d35ff742443 MD5 (6.0-BETA1-powerpc-disc1.iso) = b2562c38414ff4866f5ed8b3a38683c8 MD5 (6.0-BETA1-sparc64-bootonly.iso)
Re: dangerous situation with shutdown process
On Fri, Jul 15, 2005 at 10:11:02PM +0200, Matthias Buelow wrote.. Chuck Swiger wrote: If sysctl hw.ata.wc=0 doesn't do what you want, please submit a PR containing something better. Or buy SCSI hardware and a real, Well, if I had the time, I would. Also if instead of softupdates, a proper journalled filesystem implementation with kernel support for write barriers in the block drivers had been implemented, we wouldn't have this problem now. Ok, no point in arguing how things sigh Not If The Bloody PeeCee Style Crap ATA Drives Keep Lying To You.. Followups to /dev/null -- Wilko Bulte [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: dangerous situation with shutdown process
Matthias Buelow [EMAIL PROTECTED] writes: The combination barriers+journal really seems to be very resilient to filesystem corruption. When it's implemented without errors, and the hardware doesn't do things like change bits randomly, I can't think of a way this scheme can be corrupted at all. We keep trying to point out that barriers *can't* be enforced on the hardware with many (most, and apparently an increasing percentage of) ATA drives. There is no semantic on these drives that allows you to guarantee the journal block will be written before the corresponding data block. If you are sure that your drives do this properly, then you are safe, but in that case there's no reliability problem with softupdates, either. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Wilko Bulte wrote: sigh Not If The Bloody PeeCee Style Crap ATA Drives Keep Lying To You.. Followups to /dev/null Yes, makes no sense talking to a wall. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0-BETA1 Available
Am Freitag, 15. Juli 2005 22:12 CEST schrieb Eirik Øverby: On Jul 15, 2005, at 5:10 PM, Emanuel Strobl wrote: Am Freitag, 15. Juli 2005 16:58 CEST schrieb Marc G. Fournier: And, for the stupid question of the day ... how long before 5.x is no longer supported? I'm just about to deploy a new server, and was *going* to go with 5.x, but would I be better just skipping 5.x altogether? Or are there such drastic changes in 6.x that doing so at this time wouldn't be prudent? To post my opinion to the last part of the question: I'm also deploying new servers and I'll take RELENG_6 since there are so many improovements (nullfs in jails etc.) and 6-current has been pretty stable for me on my Hoi, what's changed wrt jails? And nullfs? I haven't been following the news as closely as I perhaps should, but I feel that the jail functionality doesn't get half as much attention in release notes as it should... Porting my jail-related tools to 5.x from 4.x was painful, but enjoyable when I was done. How does 6.x look? I'm not the developer guy so I can't tell you anything authoritative but I know that there has been an awful perfomance degradation when mounting nullfs-filesystems into a jail under RELENG_5, espacially noticable with apache! I just know that Jeff Roberson committed incredible lots of vm/vfs changes, perhaps this also solved the md performance problem, at least the nullfs problem was solved! Jail management was also a lot improved, but that was back in 5.4 I think. I'll do some extensive Jail test the next view weeks, I fear there are oddities left (I had plenty of them with milter-sender and apache's mod_proxy for example under 5.4) -Harry /Eirik UP workstation with all kinds of new stuff enabled (ULE PREEMPTION), so I guess I won't see more troubles than with 5.4, I think less :) -Harry On Fri, 15 Jul 2005, Scott Long wrote: Announcement The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 6.0-BETA1, which marks the beginning of the FreeBSD 6.0 Release Cycle. FreeBSD 6.0 will be a much less dramatic step from the FreeBSD 5 branch than the FreeBSD 5 branch was from FreeBSD 4. Much of the work that has gone into 6.0 development has focused on polishing and improving the work from 5.x These changes include streamlining direct device access in the kernel, providing a multi-threaded SMP-safe UFS/VFS filesystem layer, implementing WPA and Host-AP 802.11 features, as well as countless bugfixes and device driver improvements. Major updates and improvements have been made to ACPI power and thermal management, ATA, and many aspects of the network infrastructure. 32bit application support for AMD64 is also greatly improved, as is compatiblity with certain Athlon64 motherboards. This release is also the first to feature experimental PowerPC support for the Macintosh G3 and G4 platforms. This BETA1 release is in the same basic format as the Monthly Snapshots. For most of the architectures only the ISO images are available though the FTP install tree is available for a couple of the architectures. We encourage people to help with testing so any final bugs can be identified and worked out. Availability of ISO images is given below. If you have an older system you want to update using the normal CVS/cvsup source based upgrade the branch tag to use is RELENG_6 (though that will change for the Release Candidates later). Problem reports can be submitted using the send-pr(1) command. The list of open issues and things still being worked on are on the todo list: http://www.freebsd.org/releases/6.0R/todo.html Since this is the first release of a new branch we only have a rough idea for some of the dates. The current rough schedule is available but most dates are still listed as TBD - To Be Determined: http://www.freebsd.org/releases/6.0R/schedule.html Known Issues For the PowerPC architecture /etc/fstab isn't written out properly, so the first boot throws you into the mountroot prompt. You will need to manually enter where the root partition is and fix /etc/fstab. Also the GEM driver is listed as 'unknown' in the network config dialog. For all architectures a kernel rebuild might be needed to get some FreeBSD 5 applications to run. Add options COMPAT_FREEBSD5 to the kernel configuration file if you have problems with FreeBSD 5 executables. Availability The BETA1 ISOs and FTP support are available on most of the FreeBSD Mirror sites. A list of the mirror sites is available here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors- ftp. html The MD5s are: MD5 (6.0-BETA1-alpha-bootonly.iso) = eabda0a086e5492fe43626ce5be1d7e1 MD5 (6.0-BETA1-alpha-disc1.iso) = d7fe900bb3d5f259cc3cc565c4f303e4 MD5
Re: dangerous situation with shutdown process
Date: Fri, 15 Jul 2005 22:24:07 +0200 From: Matthias Buelow [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Wilko Bulte wrote: sigh Not If The Bloody PeeCee Style Crap ATA Drives Keep Lying To You.. Followups to /dev/null Yes, makes no sense talking to a wall. You are right, but I don't think you get who the wall is... When you try to get an ATA drive to flush its buffers and tell you when they are flushed, there is a hight probability that the drive (if it support the function at all) will tell you that it has flushed the cache immediately. There is simply no way to tell if your data or metadata is actually on the magnetic medium and no technique (journaling, barriers, soft updates) can assure that you will not have a corrupt disk, especially if the write cache is near full. Think about how long it takes to flush a 16 MB buffer to the hard drive and remember that the dump of the cache to the drive is in an order over which you have no control. The ONLY way to be really safe is to turn off the write cache and that extracts a huge performance penalty. What you prefer is a matter of personal choice but the file system simply can't make things better. I believe that the Windows solution to this problem is to put a really, really long delay between when the system is finished syncing and when the power is turned off. This might be the best solution for FreeBSD, as well, but it will irritate people. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
On Fri, 15 Jul 2005, Matthias Buelow wrote: Why am I arguing in an uphill battle here? Is data safety no longer important to the FreeBSD community? Such issues should not even have to be discussed at all! I'm trying to tell you what you have to say to move forward on this issue: 1) tell people that they are mistaken about drives ignoring the FUA bit or flush cache 2) convince people that the performance benefit of request barriers is worth it I think we all care, but when we actually care--when money depends on it-- we adopt other measures scsi, batter backed raid, etc. -Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Kevin Oberman [EMAIL PROTECTED] writes: I believe that the Windows solution to this problem is to put a really, really long delay between when the system is finished syncing and when the power is turned off. This might be the best solution for FreeBSD, as well, but it will irritate people. The Windows solution is, apparently, to disable and immediately re-enable the writeback-cache around a barrier. This will ensure the cache being written out to the platters, even if the drive ignores a flush command. Of course I don't know this for certain but have to rely on observations that others have made. See, for example: http://mail-index.netbsd.org/tech-kern/2002/12/09/0052.html The long delay at shutdown would simply be a final safeguard in case the drive also ignores disabling of the WC. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Lowell Gilbert [EMAIL PROTECTED] writes: We keep trying to point out that barriers *can't* be enforced on the hardware with many (most, and apparently an increasing percentage of) ATA drives. There is no semantic on these drives that allows you to guarantee the journal block will be written before the corresponding data block. If you are sure that your drives do this properly, then you are safe, but in that case there's no reliability problem with softupdates, either. See my other mail(s) about other systems using cache disabling/enabling to make up for a drive that ignores (or does not implement) a flush command. Then the advice of disable the wb-cache on disks to ensure data safety doesn't make sense: Either * the drive supports disabling the write-back-cache, then this method can be used to flush data to the platters, or else * the drive does not support disabling the write-back-cache, or lies about it, then the advice to disable the write-back-cache for softupdates is meaningless. I know my drive allows disabling of the write cache, as, apparently, the majority of IDE/SATA drives do. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
I know my drive allows disabling of the write cache, as, apparently, the majority of IDE/SATA drives do. Yes fair enough. This command is in the specification as far back as ata-1. I guess it yields reasonable? performance? You should, however, be telling sos@ this--if he doesn't already believe it. -Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
On Fri, 15 Jul 2005, Matthias Buelow wrote: John-Mark Gurney wrote: even request barries will not save the fs in a power loss if the track that is getting flushed durning a power loss... Some other FreeBSD folk has a reproducable case of where blocks that were not written to on ATA hardware got trashed after a power loss... With non-written to sectors getting trashed with the cache enabled, barriers don't mean squat... One more thought.. they _do_ protect against power loss during writing a track -- when used in combination with a journalled fs. A corrupted journal can be detected. If it's corrupted, discard the whole thing, or only the relevant entry. The filesystem will remain consistent. If track corruption occurs after the journal is written, it doesn't matter, since at boot the journal will be replayed and all operations will be performed once more. The track which is corrupted could contain data that wasn't written to in months. How would the journal help? The combination barriers+journal really seems to be very resilient to filesystem corruption. When it's implemented without errors, and the hardware doesn't do things like change bits randomly, I can't think of a way this scheme can be corrupted at all. I still don't trust ATA drives. Can you guarantee (or show any reason to believe) that disabling the write cache will actually wait for the cache to be flushed before returning? Otherwise a disable cacheenable cache sequence is exactly the same as a flush cache command. If the drive executes both immediately, without waiting for the cache to be flushed _before_ returning, what's the difference? -- David Taylor ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
David Taylor [EMAIL PROTECTED] writes: A corrupted journal can be detected. If it's corrupted, discard the whole thing, or only the relevant entry. The filesystem will remain consistent. If track corruption occurs after the journal is written, it doesn't matter, since at boot the journal will be replayed and all operations will be performed once more. The track which is corrupted could contain data that wasn't written to in months. How would the journal help? I don't understand this question. I still don't trust ATA drives. Can you guarantee (or show any reason to believe) that disabling the write cache will actually wait for the cache to be flushed before returning? Otherwise a disable cacheenable cache sequence is exactly the same as a flush cache command. If the drive executes both immediately, without waiting for the cache to be flushed _before_ returning, what's the difference? You imply that, because there exists one drive for which it doesn't work, that it follows that it won't work for all drives? Or what is your point? mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0-BETA1 Available
On Friday 15 July 2005 04:53 pm, Emanuel Strobl wrote: Am Freitag, 15. Juli 2005 22:12 CEST schrieb Eirik Øverby: On Jul 15, 2005, at 5:10 PM, Emanuel Strobl wrote: Am Freitag, 15. Juli 2005 16:58 CEST schrieb Marc G. Fournier: And, for the stupid question of the day ... how long before 5.x is no longer supported? I'm just about to deploy a new server, and was *going* to go with 5.x, but would I be better just skipping 5.x altogether? Or are there such drastic changes in 6.x that doing so at this time wouldn't be prudent? To post my opinion to the last part of the question: I'm also deploying new servers and I'll take RELENG_6 since there are so many improovements (nullfs in jails etc.) and 6-current has been pretty stable for me on my Hoi, what's changed wrt jails? And nullfs? I haven't been following the news as closely as I perhaps should, but I feel that the jail functionality doesn't get half as much attention in release notes as it should... Porting my jail-related tools to 5.x from 4.x was painful, but enjoyable when I was done. How does 6.x look? I'm not the developer guy so I can't tell you anything authoritative but I know that there has been an awful perfomance degradation when mounting nullfs-filesystems into a jail under RELENG_5, espacially noticable with apache! I just know that Jeff Roberson committed incredible lots of vm/vfs changes, perhaps this also solved the md performance problem, at least the nullfs problem was solved! The nullfs performace issue has been fixed. -- Anish Mistry pgpu9T1iSxoEY.pgp Description: PGP signature
