Re: Version nomenclature [was RELENG_7 to 8]
On Sat, 15 Aug 2009 01:48:27 -0400 grarpamp grarp...@gmail.com wrote: Wanted to put in a suggestion. Users are constantly confused and asking questions about the FreeBSD version naming scheme, somehow not quite picking it up right, which is which, where to use it, etc. And though I know what it is, it still seems silly to me. Because we've got logical pointers _loosely_ correlating to formal repo tag and branch names. Worst case I've seen was when FreeBSD had 4, 5, 6 all in flux at once. STABLE and CURRENT could only point to two things and there were about 10 potential tags involved. Basically, I'm proposing FreeBSD should relegate the terms STABLE and CURRENT out to the marketing portion of the web team. You can't check them out of any repo as tags, 4 and 5 were 'stable' when 6 was 'current' and so on. CURRENT means nothing more than cvs HEAD or svn trunk or git nonce. So use those terms instead of leading people think they can check out 'CURRENT' or that it has some magical command line, config file or source properties. website: 'The latest snapshots from our FreeBSD-STABLE and FreeBSD-CURRENT branches are also available'... checking out those branch names gets you HEAD. There are references to 7-STABLE, 8-CURRENT and parhaps other bastardizations on a theme :-) in the handbook that are not valid tags. STABLE is pretty much the same way, only more confusing if more than one thing is 'stable'. Back in the 4/5/6 days it could have referred to any number of branches. And on the main page, we now have more buzzwords... 'production' and 'legacy'. In fact, I'd venture that the proper place for such words, CURRENT/STABLE/production/legacy, is only on the release/download/support related pages of the website, with little '-'s to the actual tag they imply. More importanly, with descriptions that say something like which trains are developed/supported when, for how long. ie: why the deserve such words to be applied to them. Anyone who has a need to refer to CURRENT/STABLE is obviously getting beyond the release iso's and into the cvs/svn/git level of things. So just use the right terms then. Encourage people to use proper tags and for reporting bugs and things. They could probably make it into uname somehow. RELENG_x_y_RELEASE RELENG_x_y [date/serial] RELENG_x [date/serial] HEAD/trunk [date/serial] uname: '7.2-STABLE #0 date of compile' isn't quite the same solid reference as RELENG_7 as of yesterdays code. Which is what it is, not the zero-eth 7.2 errata/security/stability commit. And maybe figure out a way that each commit bumps a serial counter in UPDATING or some stampfile or uname so people can report the serial. Or maybe use the git crypto hash thing. FreeBSD needs a crypto hash reference inside the primary source tree anyways, not just on the n steps removed iso's. I dunno, just seen year after year of these questions on the lists :) Thought I'd put at least something out there. Not meant to be a bikeshed or anything. More like something to be addressed by doc project or whatever. Nice document. I believe a lot of people get confused by these situations due to a matter of not using CVS, SVN, etc... etc... and have never heard of tags and such before. While more people have heard of and used these in their own environment at one point and are not used to the scheme that FreeBSD uses. While at some point everyone should come across http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvs-tags.html not everyone has been pointed to it for reference. I feel this document states these very clearly and besides what else are you going to call the development trunk/tree for FreeBSD-STABLE FreeBSD-CURRENT ? call them both trunk ?. This is really based upon a well defined method of development that is fairly easy to understand if pointed in the right direction. A key factor in the what is RELENG_X type of situation is a Am I missing something ?, What branch am I running again ?, What branch should I pick ? and a good answer to that is right in the handbook telling yo u what these are all about. -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Version nomenclature [was RELENG_7 to 8]
In message d2e731a10908142248o6ee77e1ie89a62f3c0937...@mail.gmail.com, grarpamp (grarp...@gmail.com) wrote: [...] uname: '7.2-STABLE #0 date of compile' isn't quite the same solid reference as RELENG_7 as of yesterdays code. Which is what it is, not the zero-eth 7.2 errata/security/stability commit. If you use SVN the revision number is included in the output of uname -a and uname -v. Cheers, Nick. -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Version nomenclature [was RELENG_7 to 8]
Hi, STABLE and CURRENT could only point to two things and there were about 10 potential tags involved. Tags... You say tags. Now, freebsd is an constantly evolving project. It's never finished. And when a branch is, it's EOL. It took me two minutes, back in 97 to get the grasp and at that time the security branch had yet to be introduced, before that I tracked 'stable'. Go figure. You know, that's the beauty of this project: it's 'nix, but different. I agree with you we should find a solution about all this name-bitching: let's encourage them to actualy READ the F. manual. Let's include it in the FAQ ! Or include some pointer in UPDATING for those that like to mess with source code. Or would you like to rename STABLE into UNSTABLE ? Or FIXED ? Or into the $next_upcoming_release_number-ALPHA ? Now that sounds appealing to newcomers not. I occaisionally run a STABLE box in production without any trouble, so it's name is what you get: great software, it's stable enough. We also inject new software releases into our ports collection. I never read anything about it's name scheme. Funny, but very relieving IMO. Cheers. Robert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Multiple USB drives stability question
I am now trying to rsync large files from the 320GB gmirror+gjournal device to the 2nd 1TB gmirror+gjournal device. Using gstat I see the 320GB device active all the time while the 1TB device loads in spurts. There will be periods of multiple seconds where the target providers are completely idle while the source providers are still reporting 100% active. Is there any tuning I should be investigating for these GEOM classes? --- On Fri, 8/14/09, Jeff Richards bsd2...@yahoo.com wrote: From: Jeff Richards bsd2...@yahoo.com Subject: Re: Multiple USB drives stability question To: freebsd-stable@freebsd.org Date: Friday, August 14, 2009, 11:04 PM I just tested my 2nd 1TB gmirror device on another system with FBSD 7.2. I was getting full throughput on the drive and no lockup using bonnie++ and also monitoring with gstat. I then moved those drives back on my main server. When I booted the system I hung on the 320GB gmirror devices. Previously the 1st 1TB gmirror and 320GB gmirror were attached to the integrated USB ports on the motherboard. I moved the 320GB gmirror to a PCI USB adapter. The 2 320GB drives in the gmirror were da5 and da6. Here's what I saw on the console: (da6:umass-sim6:6:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 (da6:umass-sim6:6:0:0): CAM Status: SCSI Status Error (da6:umass-sim6:6:0:0): SCSI Status: Check Condition (da6:umass-sim6:6:0:0): ILLEGAL REQUEST asc:20,0 (da6:umass-sim6:6:0:0): Invalid command operation mode (da6:umass-sim6:6:0:0): Unretryable error GEOM_MIRROR: Request failed (error=5), da6[READ(offset=512, length=512)] GEOM_MIRROR: Device gm-san: provider da6 disconnected. (da5:umass-sim5:5:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 (da5:umass-sim5:5:0:0): CAM Status: SCSI Status Error (da5:umass-sim5:5:0:0): SCSI Status: Check Condition (da5:umass-sim5:5:0:0): ILLEGAL REQUEST asc:20,0 (da5:umass-sim5:5:0:0): Invalid command operation mode (da5:umass-sim5:5:0:0): Unretryable error GEOM_JOURNAL: BIO_FLUSH not supported by mirror/gm-san. I waited for a few minutes with no change in the console. I then detached one of the USB drives (which happened to be da6) and saw this: umass6: at uhub7 port 4 (addr 4) disconnected (da6:umass-sim6:6:0:0): lost device Nothing else changed for a few minutes so I powered off the system. When I brought it back up the 320GB gmirror device was out of sync, but apart from that all devices were online. Below are the kernel messages from the second boot: Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-RELEASE #0: Fri May 1 08:49:13 UTC 2009 r...@walker.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) CPU 2.26GHz (2266.67-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf49 Stepping = 9 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=0x441dSSE3,DTES64,MON,DS_CPL,CNXT-ID,xTPR AMD Features2=0x1LAHF real memory = 1877868544 (1790 MB) avail memory = 1826934784 (1742 MB) ACPI APIC Table: P4M900 AWRDACPI ioapic0 Version 0.3 irqs 0-23 on motherboard ioapic1 Version 0.3 irqs 24-47 on motherboard kbd1 at kbdmux0 acpi0: P4M900 AWRDACPI on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 6fde (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfe80-0xfe8003ff on acpi0 device_attach: acpi_hpet0 attach returned 12 acpi_button0: Power Button on acpi0 acpi_button1: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 vgapci0: VGA-compatible display mem 0xc000-0xcfff,0xfb00-0xfbff irq 16 at device 0.0 on pci1 pcib2: ACPI PCI-PCI bridge irq 27 at device 2.0 on pci0 pci2: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge irq 31 at device 3.0 on pci0 pci3: ACPI PCI bus on pcib3 atapci0: VIA 8237S SATA150 controller port 0xfc00-0xfc07,0xf800-0xf803,0xf400-0xf407,0xf000-0xf003,0xec00-0xec0f,0xe800-0xe8ff irq 21 at device 15.0 on pci0 atapci0: [ITHREAD] ata2: ATA channel 0 on atapci0 ata2: [ITHREAD] ata3: ATA channel 1 on atapci0 ata3: [ITHREAD] atapci1: VIA 8237S UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe400-0xe40f at device 15.1 on pci0 ata0: ATA channel 0 on atapci1 ata0: [ITHREAD] ata1: ATA channel 1 on atapci1 ata1: [ITHREAD] uhci0: VIA 83C572 USB controller port 0xe000-0xe01f irq 20 at device 16.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0:
Re: Multiple USB drives stability question
I was checking sysctl and noticed skipped_byes, alloc_failures,low_mem all increasing on geom.journal. $sysctl -a | grep geom kern.geom.collectstats: 1 kern.geom.debugflags: 0 kern.geom.label.debug: 0 kern.geom.mirror.sync_requests: 2 kern.geom.mirror.disconnect_on_failure: 1 kern.geom.mirror.idletime: 5 kern.geom.mirror.timeout: 4 kern.geom.mirror.debug: 0 kern.geom.journal.stats.low_mem: 380 kern.geom.journal.stats.journal_full: 0 kern.geom.journal.stats.wait_for_copy: 25 kern.geom.journal.stats.switches: 834 kern.geom.journal.stats.combined_ios: 5612 kern.geom.journal.stats.skipped_bytes: 34684928 kern.geom.journal.cache.alloc_failures: 14726 kern.geom.journal.cache.misses: 13894 kern.geom.journal.cache.switch: 90 kern.geom.journal.cache.divisor: 2 kern.geom.journal.cache.limit: 167772160 kern.geom.journal.cache.used: 79546368 kern.geom.journal.optimize: 1 kern.geom.journal.record_entries: 20 kern.geom.journal.parallel_copies: 16 kern.geom.journal.accept_immediately: 64 kern.geom.journal.parallel_flushes: 16 kern.geom.journal.force_switch: 70 kern.geom.journal.switch_time: 10 kern.geom.journal.debug: 0 kern.geom.virstor.component_watermark: 1 kern.geom.virstor.chunk_watermark: 100 kern.geom.virstor.debug: 2 debug.sizeof.g_geom: 68 $sysctl -a | grep geom kern.geom.collectstats: 1 kern.geom.debugflags: 0 kern.geom.label.debug: 0 kern.geom.mirror.sync_requests: 2 kern.geom.mirror.disconnect_on_failure: 1 kern.geom.mirror.idletime: 5 kern.geom.mirror.timeout: 4 kern.geom.mirror.debug: 0 kern.geom.journal.stats.low_mem: 389 kern.geom.journal.stats.journal_full: 0 kern.geom.journal.stats.wait_for_copy: 28 kern.geom.journal.stats.switches: 838 kern.geom.journal.stats.combined_ios: 5622 kern.geom.journal.stats.skipped_bytes: 35667968 kern.geom.journal.cache.alloc_failures: 15016 kern.geom.journal.cache.misses: 15079 kern.geom.journal.cache.switch: 90 kern.geom.journal.cache.divisor: 2 kern.geom.journal.cache.limit: 167772160 kern.geom.journal.cache.used: 73140224 kern.geom.journal.optimize: 1 kern.geom.journal.record_entries: 20 kern.geom.journal.parallel_copies: 16 kern.geom.journal.accept_immediately: 64 kern.geom.journal.parallel_flushes: 16 kern.geom.journal.force_switch: 70 kern.geom.journal.switch_time: 10 kern.geom.journal.debug: 0 kern.geom.virstor.component_watermark: 1 kern.geom.virstor.chunk_watermark: 100 kern.geom.virstor.debug: 2 debug.sizeof.g_geom: 68 --- On Sat, 8/15/09, Jeff Richards bsd2...@yahoo.com wrote: From: Jeff Richards bsd2...@yahoo.com Subject: Re: Multiple USB drives stability question To: freebsd-stable@freebsd.org Date: Saturday, August 15, 2009, 10:50 AM I am now trying to rsync large files from the 320GB gmirror+gjournal device to the 2nd 1TB gmirror+gjournal device. Using gstat I see the 320GB device active all the time while the 1TB device loads in spurts. There will be periods of multiple seconds where the target providers are completely idle while the source providers are still reporting 100% active. Is there any tuning I should be investigating for these GEOM classes? --- On Fri, 8/14/09, Jeff Richards bsd2...@yahoo.com wrote: From: Jeff Richards bsd2...@yahoo.com Subject: Re: Multiple USB drives stability question To: freebsd-stable@freebsd.org Date: Friday, August 14, 2009, 11:04 PM I just tested my 2nd 1TB gmirror device on another system with FBSD 7.2. I was getting full throughput on the drive and no lockup using bonnie++ and also monitoring with gstat. I then moved those drives back on my main server. When I booted the system I hung on the 320GB gmirror devices. Previously the 1st 1TB gmirror and 320GB gmirror were attached to the integrated USB ports on the motherboard. I moved the 320GB gmirror to a PCI USB adapter. The 2 320GB drives in the gmirror were da5 and da6. Here's what I saw on the console: (da6:umass-sim6:6:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 (da6:umass-sim6:6:0:0): CAM Status: SCSI Status Error (da6:umass-sim6:6:0:0): SCSI Status: Check Condition (da6:umass-sim6:6:0:0): ILLEGAL REQUEST asc:20,0 (da6:umass-sim6:6:0:0): Invalid command operation mode (da6:umass-sim6:6:0:0): Unretryable error GEOM_MIRROR: Request failed (error=5), da6[READ(offset=512, length=512)] GEOM_MIRROR: Device gm-san: provider da6 disconnected. (da5:umass-sim5:5:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 (da5:umass-sim5:5:0:0): CAM Status: SCSI Status Error (da5:umass-sim5:5:0:0): SCSI Status: Check Condition (da5:umass-sim5:5:0:0): ILLEGAL REQUEST asc:20,0 (da5:umass-sim5:5:0:0): Invalid command operation mode (da5:umass-sim5:5:0:0): Unretryable error GEOM_JOURNAL: BIO_FLUSH not supported by mirror/gm-san. I waited for a few minutes with no change in the console. I then detached one of the USB drives (which happened to be da6) and saw this: umass6: at uhub7 port 4 (addr 4) disconnected (da6:umass-sim6:6:0:0): lost device Nothing else changed for a few minutes so I powered off the system. When I brought it back up
Re: Going to BSD 8 from RELENG_7
Dan Allen wrote: I cvsup and build RELENG_7 many times a week. This has served me well (except for the ZFS boot problem I had that went in and was backed out) for quite a while. I like to track a STABLE release. When BSD 7 went to 7.1 and to 7.2, it all just happened automatically with the way I do things. Now I am interested on one of my BSD machines to try 8.0. I need to change my cvsup target from RELENG_7 to CURRENT I believe. Is that true? When will STABLE become 8.0? Minor terminology issue, STABLE is not the name of one version of FreeBSD, it is the label appended to the version number during the ongoing development of the branch after a release. So there are currently 6.4-STABLE and 7.2-STABLE branches, and after 8.0-RELEASE there will be an 8.0-STABLE. BTW, the -STABLE name refers to the API in that branch, as well as (hopefully) the fact that running it should be safe/stable. If you're interested in testing the new 8.0 version before it is released we would all be very glad to have you do that. :) The more testers we get before release the more certain we can be that there are no problems with it. I would like to make one suggestion though, if you could hold off until the 8.0-BETA3 is ready and test a clean install using the cd iso image that would be great! We never get enough people testing clean installations so this is something that is very valuable. Obviously however you test this you'd want to back up your data and any relevant configuration stuff first. Oh, and any feedback on your experiences can go to the freebsd-current mailing list until after the release. Good luck, Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Multiple USB drives stability question
Jeff,
On 15 aug 2009, at 05:04, Jeff Richards wrote:
(da6:umass-sim6:6:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0
0 0
...
I've had lots of stability issues with USB drives until I added some
quirks to prevent the SYNCHRONIZE CACHE from happening. For example:
Index: cam/scsi/scsi_da.c
===
RCS file: /usr/ncvs/src/sys/cam/scsi/scsi_da.c,v
retrieving revision 1.224.2.6
diff -r1.224.2.6 scsi_da.c
539a540,547
* LaCie external 250GB Hard drive designed by Porsche
* PR: usb/121474
*/
{T_DIRECT, SIP_MEDIA_FIXED, SAMSUNG, HM250JI, *},
/*quirks*/ DA_Q_NO_SYNC_CACHE
},
{
/*
You might try that, and see if it improves your situation.
Ben
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
