Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 01/20/12 09:13, John Kozubik wrote: I normally hate to dredge up old threads, but this is like getting halfway through a story and not finding out the ending... :) What is the answer? Is there a solution to this? I have a string of questions on this: 1. Incidentally, what exactly does constitute a major release? 2. Is there a reason to update the numbers so quickly? 3. Could a higher bar be set to reach a major release than simply temporal objectives? One of the differentiating factors between linux and FreeBSD is the simple fact that linux distros tend to run so fast through the numbers- and while just a matter of perspective, it could provide some sense of stability to enterprise users. Weighed against, of course, the ability to upgrade easily. 4. If in the case of the former, could some backporting to the stable and release branches facilitate an easy upgrade to the next major release? 5. Could binaries be the answer to easier upgrades (customised for enterprise users)? I'd really like to know the OP's thoughts on this... Cheers ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Thursday, January 19, 2012 4:33:40 pm Adrian Chadd wrote: On 19 January 2012 09:47, Mark Saad nones...@longcount.org wrote: I just want to chime in here, what is the deal with killing off a potential 7.5-RELEASE ? Having a few 7.3-RELEASE and 7.4-RELEASE servers I would like to see a 7.5-RELEASE that is supported to 2015 to prevent another major upgrade cycle . There are still freebsd developers working on 7-STABLE and its been reliable and working for me and I am sure a few other people. What could I do to help make 7.5-RELEASE a reality ? Put your hand up and volunteer to run the 7.5-RELEASE release cycle. That's not actually true or really fair. There has to be some buy-in from the project to do an official release; it is not something that a single person can do off in a corner and then have the Project bless the bits as an official release. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Speeding up the loader(8).
On Tuesday, January 24, 2012 1:22:57 pm Artem Belevich wrote: 2012/1/23 Edward Tomasz Napierała tr...@freebsd.org: Some time ago I've spent some time on trying to speed up loading modules by the loader(8). Result can be found at: http://people.freebsd.org/~trasz/fast-loader-3.diff This patch solves three issues: 1. As it is now, the code in biosdisk.c tries very hard to split reasonably sized (up to 64kB, IIRC) requests into smaller ones. It is more that the I/O's cannot cross a 64kb boundary. This is due to a limitation in old disk controllers. Newer versions of EDD provide flags that indicate whether a device needs this to be honored or not. You could use these flags from EDD to determine if the splitting should be used or not which might help with your case while still being safe for older devices (and for some more limited devices such as flash). EDD3 can also let you specify the raw 64-bit physical address to write the bits into rather than always using a bounce buffer in the low 1MB. This would also be a good thing to take advantage of. 2. The code in biosdisk.c rereads the partition table and probably some filesystem metadata every time a file gets opened, i.e. for every module. These reads bypass the bcache. 3. The code in bcache.c doesn't really implement an LRU - it implements 'least recently added' algorithm, i.e. a kind of queue. Not that it matters much, since it flushes the elements two seconds after caching them anyway. I replaced it with Least Frequently Used. LRU didn't behave well, as it tended to replace metadata with data used only once. These sound reasonable, though I suspect they are in part due to dealing with floppies where the user can swap out of the disk and we have no way of noticing otherwise. However, we could possibly adjust some behavior to cache the bits if the disk is not a floppy drive. 4. it flushes cache on access to a different drive which means that cache does not help on multi-disk ZFS setups. I believe this is also necessary to deal with floppies and the fact that you don't have a reliable way of knowing if a floppy has changed. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 26 Jan 2012, at 14:37, John Baldwin wrote: On Thursday, January 19, 2012 4:33:40 pm Adrian Chadd wrote: On 19 January 2012 09:47, Mark Saad nones...@longcount.org wrote: What could I do to help make 7.5-RELEASE a reality ? Put your hand up and volunteer to run the 7.5-RELEASE release cycle. That's not actually true or really fair. There has to be some buy-in from the project to do an official release; it is not something that a single person can do off in a corner and then have the Project bless the bits as an official release. And raises the interesting question for an outsider of a) who is the project in this case and b) what does it take for a release to be a release? Wasn't there a freebsd-releng (or similar) mailing list ages ago? I didn't spot an active one at http://docs.freebsd.org/mail/ - Mark___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Speeding up the loader(8).
On Thu, Jan 26, 2012 at 6:54 AM, John Baldwin j...@freebsd.org wrote: 3. The code in bcache.c doesn't really implement an LRU - it implements 'least recently added' algorithm, i.e. a kind of queue. Not that it matters much, since it flushes the elements two seconds after caching them anyway. I replaced it with Least Frequently Used. LRU didn't behave well, as it tended to replace metadata with data used only once. These sound reasonable, though I suspect they are in part due to dealing with floppies where the user can swap out of the disk and we have no way of noticing otherwise. However, we could possibly adjust some behavior to cache the bits if the disk is not a floppy drive. 4. it flushes cache on access to a different drive which means that cache does not help on multi-disk ZFS setups. I believe this is also necessary to deal with floppies and the fact that you don't have a reliable way of knowing if a floppy has changed. Are floppies still relevant? When I attempted to address your concern about floppies that you raised when I've sent my patch, I've discovered that there's no floppy connector on any of the computers/motherboards that I have. Few years back I was amused by an Intel motherboard that came with a floppy disk with RAID drivers on it, but which had no floppy connector on the motherboard. In any case, it's easy enough to enforce old behavior for floppy drives. I will make required changes but I will not be able to test it due to lack of floppy drives. --Artem ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Thursday, January 26, 2012 11:49:22 am Mark Blackman wrote: On 26 Jan 2012, at 14:37, John Baldwin wrote: On Thursday, January 19, 2012 4:33:40 pm Adrian Chadd wrote: On 19 January 2012 09:47, Mark Saad nones...@longcount.org wrote: What could I do to help make 7.5-RELEASE a reality ? Put your hand up and volunteer to run the 7.5-RELEASE release cycle. That's not actually true or really fair. There has to be some buy-in from the project to do an official release; it is not something that a single person can do off in a corner and then have the Project bless the bits as an official release. And raises the interesting question for an outsider of a) who is the project in this case and b) what does it take for a release to be a release? I'll answer the two together. The project is the entity that owns freebsd.org and a release is not a release unless it is present on ftp.freebsd.org and has a signed announcement e-mail with hashes, etc. on the freebsd-announce@ mailing list. Without those things there is no reason for a user to believe that a particular set of bits is a legitimate FreeBSD release. Additionally, a release should be available via the appropriate tags in the CVS and SVN repositories available from freebsd.org machines. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Speeding up the loader(8).
On Thu, Jan 26, 2012 at 10:22 AM, Artem Belevich a...@freebsd.org wrote: On Thu, Jan 26, 2012 at 6:54 AM, John Baldwin j...@freebsd.org wrote: 3. The code in bcache.c doesn't really implement an LRU - it implements 'least recently added' algorithm, i.e. a kind of queue. Not that it matters much, since it flushes the elements two seconds after caching them anyway. I replaced it with Least Frequently Used. LRU didn't behave well, as it tended to replace metadata with data used only once. These sound reasonable, though I suspect they are in part due to dealing with floppies where the user can swap out of the disk and we have no way of noticing otherwise. However, we could possibly adjust some behavior to cache the bits if the disk is not a floppy drive. 4. it flushes cache on access to a different drive which means that cache does not help on multi-disk ZFS setups. I believe this is also necessary to deal with floppies and the fact that you don't have a reliable way of knowing if a floppy has changed. Are floppies still relevant? When I attempted to address your concern about floppies that you raised when I've sent my patch, I've discovered that there's no floppy connector on any of the computers/motherboards that I have. Few years back I was amused by an Intel motherboard that came with a floppy disk with RAID drivers on it, but which had no floppy connector on the motherboard. In any case, it's easy enough to enforce old behavior for floppy drives. I will make required changes but I will not be able to test it due to lack of floppy drives. USB-based floppy drives are still common. We use them to upgrade firmware, upgrade BIOS, install drivers, etc on our servers ... none of which have floppy headers on the motherboard. But the BIOSes still support floppies, and floppies are still used a lot (unfortunately). Now, whether or not a floppy-based loader would be useful for FreeBSD ... -- Freddie Cash fjwc...@gmail.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 26 Jan 2012, at 18:22, John Baldwin wrote: On Thursday, January 26, 2012 11:49:22 am Mark Blackman wrote: a) who is the project in this case and b) what does it take for a release to be a release? I'll answer the two together. The project is the entity that owns freebsd.org and a release is not a release unless it is present on ftp.freebsd.org and has a signed announcement e-mail with hashes, etc. on the freebsd-announce@ mailing list. Without those things there is no reason for a user to believe that a particular set of bits is a legitimate FreeBSD release. Additionally, a release should be available via the appropriate tags in the CVS and SVN repositories available from freebsd.org machines. Thanks. I wonder who that entity is? Everyone with a commit bit, or perhaps just the RE team? Anyway, it's not very important in this context. I also tracked this down, but might be out of date. http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/release-proc.html New releases of FreeBSD are released from the -STABLE branch at approximately four month intervals. To be honest, I'm sure we all agree this sort of discussion is not useful on hackers and obviously at some point needs to turn into work rather than points of view. Mostly it just boils down, lets see if we can do -STABLE point releases a bit more frequently. - Mark ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 26 Jan 2012, at 22:49, Mark Linimon wrote: On Thu, Jan 26, 2012 at 10:23:43PM +, Mark Blackman wrote: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/release-proc.html New releases of FreeBSD are released from the -STABLE branch at approximately four month intervals. That was our intention at one point. Obviously we've not stuck to that. (IMHO doing releases quite that frequently is probably beyond what we can do with volunteer staffing, but I'm not on re@ so take it as you will.) In any case, various people within the project have now absorbed the lesson that 10 months between releases is too long, and are trying to figure out what to do about it. Indeed, I was just reviewing the last couple of years of release and the thing that struck me was the number of BETAs and RCs for each point release. I suspect poor old RE is putting too much work into BETAs and RCs for point releases. - Mark___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Thu, Jan 26, 2012 at 10:23:43PM +, Mark Blackman wrote: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/release-proc.html New releases of FreeBSD are released from the -STABLE branch at approximately four month intervals. That was our intention at one point. Obviously we've not stuck to that. (IMHO doing releases quite that frequently is probably beyond what we can do with volunteer staffing, but I'm not on re@ so take it as you will.) In any case, various people within the project have now absorbed the lesson that 10 months between releases is too long, and are trying to figure out what to do about it. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
Mark Blackman wrote: On 26 Jan 2012, at 14:37, John Baldwin wrote: On Thursday, January 19, 2012 4:33:40 pm Adrian Chadd wrote: On 19 January 2012 09:47, Mark Saad nones...@longcount.org wrote: What could I do to help make 7.5-RELEASE a reality ? Put your hand up and volunteer to run the 7.5-RELEASE release cycle. That's not actually true or really fair. There has to be some buy-in from the project to do an official release; it is not something that a single person can do off in a corner and then have the Project bless the bits as an official release. And raises the interesting question for an outsider of a) who is the project in this case and b) what does it take for a release to be a release? Wasn't there a freebsd-releng (or similar) mailing list ages ago? I am going to avoid the above question, since I don't know the answer and I believe other(s) have already answered it. However, I will throw out the following comment: I can't seem to find the post, but someone suggested a release mechanism where stable/N would simply be branched when it appeared to be in good shape. Although I have no idea if this is practical for all releases, it seems that it might be a low overhead approach for releases off old stable branches like stable/7 currently is? (ie. Since there aren't a lot of commits happening to stable/7, just branch it. You could maybe give a one/two week warning email about when this will happen. I don't think it would cause a flurry of commits like happens when code slush/freeze approaches for a new .0 one.) Just a thought, rick ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Thu, Jan 26, 2012 at 10:52:44PM +, Mark Blackman wrote: I suspect poor old RE is putting too much work into BETAs and RCs for point releases. The counter-argument is that we have a lot more leeway to make mistakes on a .0 release. We're not going to be cut any slack at all for shipping a badly regressed point release. Some minor regressions are inevitable in software, but they do indeed need to be minor. For how we're doing with regressions in general, see: http://people.freebsd.org/~linimon/studies/prs/prs_for_tag_regression.html Now, it's true that many of the recent PRs are against 9.0, and many of the ones that aren't may be stale (certainly most of the pre-2010 ones), but these are the types of things that users really notice and become unhappy about. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
