Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
On Sat, 1 May 1999, Jordan K. Hubbard wrote: My suggestion would be to wait and see how bitkeeper pans out. Enough people in the Linux camp have already looked at CVSup and gone ooh, sexy! that I think there will already be significant pressure to develop similar tools for the bitkeeper environment. When that happens, we can start to look at this more seriously. I think that's wise. I'd also recommend people check out Bitkeeper's license before making any final decisions. It's not GPL, BSD, or any other Open Source license. Brian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
On Wed, 5 May 1999, Brian Behlendorf wrote: On Sat, 1 May 1999, Jordan K. Hubbard wrote: My suggestion would be to wait and see how bitkeeper pans out. Enough people in the Linux camp have already looked at CVSup and gone ooh, sexy! that I think there will already be significant pressure to develop similar tools for the bitkeeper environment. When that happens, we can start to look at this more seriously. I think that's wise. I'd also recommend people check out Bitkeeper's license before making any final decisions. It's not GPL, BSD, or any other Open Source license. This entire BitKeeper discussion is totally worthless. We're not gonna change. Anyone here want to give up cvsup? Or kick away from a terminal addiction to ctm (and believe me, those ctm'ers are real happily addicted). The answer is no. Face it, it's *possible* that there are better management tools than cvs, but it's for darn sure we can't do better than cvsup/ctm. This discussion merits dropping, at least until someone rewrites cvsup ctm. Don't hold your breath. +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
In article pine.bsf.4.10.9905051835560.388-100...@picnic.mat.net, Chuck Robey chu...@picnic.mat.net wrote: This discussion merits dropping, at least until someone rewrites cvsup ctm. Don't hold your breath. I haven't looked at bitkeeper, but I doubt anybody would have to _rewrite_ CVSup. It would just require that a new update method be added to handle whatever their files look like in an intelligent way. Until that was done, it's likely that CVSup's rsync method could handle them reasonbly well. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
In message 19990502015216.a...@keltia.freenix.fr Ollivier Robert writes: : WHat are the improvements compared to Perforce ? After working with Perforce for 9 month at Pluto, I'd have to say it is head and shoulders above CVS. It is a different style of source management, where you have to explicitly open things, but its ability to deal with branches has made it possible to have an extensive set of changes from FreeBSD for pluto boxes and still stay sane. And deal with multiple branches, and deal well with merging. CVSup is still faster at updates that perforce, however... Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
In message pine.lnx.4.04.9905011928550.735-100...@feral.com Matthew Jacob writes: : Oh, very well, I'll have to say Perforce isn't that bad- it's just that it : doesn't have a snappy set of tcl/tk GUI tools that allow you look at whole : branch and revision histories.. I've seen many Tk tools that do this. There is also a web interface as well. : It doesn't have a 3-way filemerge tool (I : still fire up teamware (what NSElite became) to do heavy merging and use : the automerge feature)... That is true. : Perforce *does* have the disparate release : stream feature, but I have found it somewhat difficult to use. Perhaps if : I'd actually had the depot locally I'd feel more at home with it Once you get use to it, it is much easier to use than CVS. I have my own branch for kernel changes that I'm in the middle of, and merging them is as simple as p4 integrate newsrc/sys/... src/sys/... p4 resolve And I can also merge the changes to my src/sys/... tree back into newsrc/sys/... at any time with p4 integrate src/sys/... newsrc/sys/... p4 resolve I'd go insane without it. Or more likely people at work would be more upset with my tendancy to checkin early and often to make sure all the places I work on stuff are in sync. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
RW == Robert Watson rob...@cyrus.watson.org writes: RW So will bitkeeper provide a nice interface for migrating code RW from an existing and well-established CVS repository to RW whatever they use? I've looked at bitkeeper and wonder what exactly are it's advantages over CVS. It's model looks very much geared towards the fragmented way Linux is developed, offering no advantages for more centralized models such as FreeBSD or most commercial internal environments. In the Linux environment the 'patch' is everything, and the kernel looks like a big pile of 'patches' to me. Thus in bitkeeper generating these patch sets (containing history log messages) to submit from one repository to another is important, because people exchange patches all the time. The other thing is some graphic tools (written in tcl/tk) but there are also some of such GUI layers for CVS, though they've never become very popular because the command line (combined with UNIX pipes std. commands, filters) cannot be beaten for this type of work IMO. I'd suggest to at least wait a (long) while to see how it is developing. At the moment I see absolutely no advantage for more centralized development models. -- Peter Mutsaers | Abcoude (Utrecht), | Trust me, I know p...@xs4all.nl | the Netherlands| what I'm doing. ---+-+-- Running FreeBSD-current UNIX. See http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
Matthew Jacob wrote... Oh, very well, I'll have to say Perforce isn't that bad- it's just that it doesn't have a snappy set of tcl/tk GUI tools that allow you look at whole branch and revision histories.. I know there's a reasonable web-based tool that lets you look at revision histories for files, trees, whatever. There's also a nice tcl/tk tool that allows you to do merge files from a gui interface. It doesn't have a 3-way filemerge tool (I still fire up teamware (what NSElite became) to do heavy merging and use the automerge feature)... Perforce *does* have the disparate release stream feature, but I have found it somewhat difficult to use. Perhaps if I'd actually had the depot locally I'd feel more at home with it What do you mean by 3-way merge? I've got one souce tree under perforce that is an amalgamtion of 5 source trees. Right now, I'm actively keeping it in sync with two separate source trees. And this is a non-trivial number of files -- each of the trees in question is at least a full FreeBSD source tree. Perforce's merging tools work pretty well, and have enabled me to do some branching and merging that would probably drive even a seasoned CVS user nuts. Here's how I generally merge things from two branches into a combined branch: p4 integrate -b branch1-to-combined-branch [ The -b argument specifies the branch mapping, which basically is the source and destination trees ] p4 resolve -as [ This tells perforce to resolve the merge, and accept safe changes. Safe changes are changes to files that have changed in the source or destination branches, but not both. ] p4 resolve [ This picks up the files that weren't automatically merged in the last step. For most files, perforce is able to merge things adequately, but when it can't, you have to go in and edit things manually, or specify whether you want to keep the source or destination branch version of the file. ] p4 submit [ Write a change description, edit the list of files to submit, and then check things in. ] You then repeat the same process for the second branch merge, except that in the first step, you'd use a different branch mapping. It's also pretty easy to merge things in the opposite direction. You can also do nifty things like only merge certain files from one branch to another, or only merge certain changes from one branch to another. It's possible, for instance, to merge revisions 4, 5, 7, and 9 of a file, but not 6 or 8. It's also possible to merge certain changelists from one branch to another, instead of doing a blanket merge. Ken -- Kenneth Merry k...@plutotech.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
On Fri, 30 Apr 1999, Kevin Day wrote: To sum it all up is there any difference between the branches? Yes. We hope that people like you will help us by participating in the testing of potential releases _before_ they go out as releases, not _afterwards_. Sitting around doing nothing and then complaining after the fact doesn't help anyone, least of all yourself. This isn't meant in a bad way, but let me share with you my experiences. Before 3.0 was released, I said several times Hey, NFS got a lot worse on -CURRENT. Is anyone looking at this? and got several replies of Duh, this is -CURRENT. Don't whine about it. If you're trying to use this in a production environment, you're crazy. After 3.0 was released, I said Hey, 3.0 got released, and NFS was still broken, to which I got Why didn't you bug us about this before the release? and/or Why didn't you test this before release? I understand NFS is a 'special' problem, but for those of us not in the trenches coding, I think the '3-level' system would be better. -CURRENT for those who are coding, -BETA for people like me to test things and bring up what broke, and -RELEASE for everyone else. I honestly don't know when to bring up things like that, now. :) I don't think a 3 branch system is workable for the simple reason that CVS doesn't handle branches at all well. One possible alternative would be the same structure that we have today with the addition of a 'last known good' tag which is on the head branch and slides forward when a feature is deemed 'good'. People who want features but don't want to fix them can use this tag. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
I honestly don't know when to bring up things like that, now. :) For 3.2, _right_now_. What you're doing with Matt is the first stage; the next involves bringing it back to the 3.2-beta tree and testing it there. Please understand that if you (the community) aren't working on this, nobody else is. We don't have enough people manning the trenches because they're all sitting back in the chateau waiting for the afternoon dispatches. This doesn't work. 8) Can I propose something? I realize gnats does most of this, but... Suppose there's some central list where anyone who is having unresolved problems can post their e-mail address, section of code, and a brief explaination of the symptoms. Other people acn go to this list and tack on their e-mail address to other people's compalaints saying I'm seeing this too.. Before each release, all of these people are e-mailed saying Can you test to see if your problem still exists? This will also be a bonus for developers to find people who are experiencing specific problems, to see if their fixes work. I know this is a lot like gnats, however: I don't think gnats wants a list of 'me too's in it. It's not easy to mail groups of people from gnats. There's no reason for anyone to add their e-mail address to a PR at the moment. I'm not sure if this'll make things more confusing or not, but... It'll stop people with legitimate problems from getting lost in the shuffle, and keeps PR's to more timely issues. Anyone have any comments? Really, i'm just picturing a list of people with specific problems... maybe gnats can be tuned a bit for this... Kevin To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
BitKeeper should be ready soon. Once it's been proven stable, might it be a better alternative to CVS? H To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
:BitKeeper should be ready soon. : :Once it's been proven stable, might it be a better alternative to CVS? : :H Maybe, but we wouldn't know for a couple of years. You don't just go trusting 15+ years worth of source history to a program that has just barely been written. I think the Linux people are making a huge mistake by not using CVS. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
On Sat, 1 May 1999, Matthew Dillon wrote: # #:BitKeeper should be ready soon. #: #:Once it's been proven stable, might it be a better alternative to CVS? #: #:H # # Maybe, but we wouldn't know for a couple of years. You don't just go # trusting 15+ years worth of source history to a program that has just # barely been written. I think the Linux people are making a huge mistake # by not using CVS.
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
# #:BitKeeper should be ready soon. #: #:Once it's been proven stable, might it be a better alternative to CVS? #: #:H # # Maybe, but we wouldn't know for a couple of years. You don't just go # trusting 15+ years worth of source history to a program that has just # barely been written. I think the Linux people are making a huge mistake # by not using CVS. From what I gather (and I could very well be wrong), but I think BitKeeper is somewhat based on SCCS. I'm not advocating that we ditch CVS either, just that BitKeeper may not be as new and fresh as some would like us to believe. Looks like an old friend (or nemisis) dressed in a new set of rags. :) No, not really. Larry's hostile to RCS because of it's lack of checksum. I've asked him about it a couple of times and he's not really excited about an RCS bottom end. It could be done if you insisted on it (I mean, it's GPL'd code, right?) but it's not something he would support. Bitkeeper is a substantial improvement over CVS and Perforce. It's really a nice piece of work done by somebody who *really* knows his stuff. Remember that Larry saved Sun from complete disaster by inventing NSElite (which Bitkeeper is emphatically a granchild of) in time to keep 1000 engineers from rising up and tearing Eric Schmidt to threads over his insistence that The Sun/SVR4 merge *SHALL* use NSE and the [ broken ] translucent filesystem if we're here until the year 2000 doing it!. Personally, I'm happy with CVS if you have a model a single main stream of development. It's a disaster when you have to maintain separate development clusters. And very few other packages really do any kind of job of this either. Look- if Linux adopts Bitkeeper, you really should pay attention to that. I doubt you'd find a more difficult set of software engineers to keep code in sync for than the Linux folks- if Bitkeeper works for them and essentially makes a rational release train for Linux, then a major glaring flaw in Linux' strategy that keeps serious businesses from really being able to trust it will be removed. Think about it. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: solid NFS patch #6 avail for -current - need testers files)
-Original Message- From: Matthew Dillon [mailto:dil...@apollo.backplane.com] Sent: 01 May 1999 18:24 To: Harlan Stenn Cc: Doug Rabson; Kevin Day; Mike Smith; da...@aps-services.com; p...@originative.co.uk; freebsd-current@FreeBSD.ORG Subject: Re: solid NFS patch #6 avail for -current - need testers files) :BitKeeper should be ready soon. : :Once it's been proven stable, might it be a better alternative to CVS? : :H Maybe, but we wouldn't know for a couple of years. You don't just go trusting 15+ years worth of source history to a program that has just barely been written. I think the Linux people are making a huge mistake by not using CVS. 15 years? Our cvs repository is only about 5 years old and cvs isn't 15 years old! I agree with the sentiment though :-) Although, if it's widely used I suspect it will stabilise much sooner than a couple of years. If it has the required features it might be worth playing with on the back burner to see how it shaped up. Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
So will bitkeeper provide a nice interface for migrating code from an existing and well-established CVS repository to whatever they use? I'm quite happy to allow them to test bitkeeper in a production environment before using it in one myself, needless to say. :) On Sat, 1 May 1999, Matthew Jacob wrote: # #:BitKeeper should be ready soon. #: #:Once it's been proven stable, might it be a better alternative to CVS? #: #:H # # Maybe, but we wouldn't know for a couple of years. You don't just go # trusting 15+ years worth of source history to a program that has just # barely been written. I think the Linux people are making a huge mistake # by not using CVS. From what I gather (and I could very well be wrong), but I think BitKeeper is somewhat based on SCCS. I'm not advocating that we ditch CVS either, just that BitKeeper may not be as new and fresh as some would like us to believe. Looks like an old friend (or nemisis) dressed in a new set of rags. :) No, not really. Larry's hostile to RCS because of it's lack of checksum. I've asked him about it a couple of times and he's not really excited about an RCS bottom end. It could be done if you insisted on it (I mean, it's GPL'd code, right?) but it's not something he would support. Bitkeeper is a substantial improvement over CVS and Perforce. It's really a nice piece of work done by somebody who *really* knows his stuff. Remember that Larry saved Sun from complete disaster by inventing NSElite (which Bitkeeper is emphatically a granchild of) in time to keep 1000 engineers from rising up and tearing Eric Schmidt to threads over his insistence that The Sun/SVR4 merge *SHALL* use NSE and the [ broken ] translucent filesystem if we're here until the year 2000 doing it!. Personally, I'm happy with CVS if you have a model a single main stream of development. It's a disaster when you have to maintain separate development clusters. And very few other packages really do any kind of job of this either. Look- if Linux adopts Bitkeeper, you really should pay attention to that. I doubt you'd find a more difficult set of software engineers to keep code in sync for than the Linux folks- if Bitkeeper works for them and essentially makes a rational release train for Linux, then a major glaring flaw in Linux' strategy that keeps serious businesses from really being able to trust it will be removed. Think about it. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Robert N Watson rob...@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 Carnegie Mellon Universityhttp://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
As I understand it, BitKeeper is indeed based on SCCS, and is a superset of it. The performance hit of SCCS has been solved. There are several significant commercial users of BitKeeper waiting for the first production release, and Larry McVoy seems to be a bit of a maniac when it comes to things being production stable. He said that a CVS-BitKeeper conversion tool is not far off. I'm mostly interested in the lines of development features, the ability to check in various revisions of my *local* work, the ability to apply a patch set as an atomic unit, and several of the GUI tools. H To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: RE: solid NFS patch #6 avail for -current - need testers files)
: trusting 15+ years worth of source history to a program : that has just : barely been written. I think the Linux people are making : a huge mistake : by not using CVS. : :15 years? Our cvs repository is only about 5 years old and cvs isn't 15 :years old! Well, ok, this reposity only goes as far back as 4.4-lite. I was being inclusive :-) -Matt Matthew Dillon dil...@backplane.com :I agree with the sentiment though :-) : :Although, if it's widely used I suspect it will stabilise much sooner than a :couple of years. If it has the required features it might be worth playing :with on the back burner to see how it shaped up. : :Paul. : To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
So will bitkeeper provide a nice interface for migrating code from an existing and well-established CVS repository to whatever they use? They have tools for RCS to SCCS- I dunno about CVS tho... I'm quite happy to allow them to test bitkeeper in a production environment before using it in one myself, needless to say. :) fair enuff To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
As I understand it, BitKeeper is indeed based on SCCS, and is a superset of it. The performance hit of SCCS has been solved. There are several significant commercial users of BitKeeper waiting for the first production release, and Larry McVoy seems to be a bit of a maniac when it comes to things being production stable. He said that a CVS-BitKeeper conversion tool is not far off. Cool! I'm mostly interested in the lines of development features, the ability to check in various revisions of my *local* work, the ability to apply a patch set as an atomic unit, and several of the GUI tools. Amen to that To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
On Sat, 1 May 1999, Matthew Dillon wrote: :BitKeeper should be ready soon. : :Once it's been proven stable, might it be a better alternative to CVS? : :H Maybe, but we wouldn't know for a couple of years. You don't just go trusting 15+ years worth of source history to a program that has just barely been written. I think the Linux people are making a huge mistake by not using CVS. My thoughts almost exactly (I think the Linux people have already made a huge mistake and are compounding it). -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
:BitKeeper should be ready soon. : :Once it's been proven stable, might it be a better alternative to CVS? : :H Maybe, but we wouldn't know for a couple of years. You don't just go trusting 15+ years worth of source history to a program that has just barely been written. I think the Linux people are making a huge mistake by not using CVS. My thoughts almost exactly (I think the Linux people have already made a huge mistake and are compounding it). But they are using CVS- sparclinux has been under anon CVS for years. The problem with CVS is that it *just doesn't work* if you try and have truly separate development streams. Branches and corrupted trees and directory renames are as pleasant and easy in CVS as trying to deal with Charles Hannum and Jason Thorpe in NetBSD (crazed weasels on angel dust going for your nether body parts is a comparative tickle). And don't even *begin* to talk about merging... Don't get me wrong- *I* like CVS and how it's used for FreeBSD right now. But if you begin to have separate branch development models and want to really have a flexible source tree that you can repartition and repackage at will, CVS is not your friend. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
On Sat, 1 May 1999, Matthew Jacob wrote: :BitKeeper should be ready soon. : :Once it's been proven stable, might it be a better alternative to CVS? : :H Maybe, but we wouldn't know for a couple of years. You don't just go trusting 15+ years worth of source history to a program that has just barely been written. I think the Linux people are making a huge mistake by not using CVS. My thoughts almost exactly (I think the Linux people have already made a huge mistake and are compounding it). But they are using CVS- sparclinux has been under anon CVS for years. The problem with CVS is that it *just doesn't work* if you try and have truly separate development streams. Branches and corrupted trees and directory renames are as pleasant and easy in CVS as trying to deal with Charles Hannum and Jason Thorpe in NetBSD (crazed weasels on angel dust going for your nether body parts is a comparative tickle). And don't even *begin* to talk about merging... Don't get me wrong- *I* like CVS and how it's used for FreeBSD right now. But if you begin to have separate branch development models and want to really have a flexible source tree that you can repartition and repackage at will, CVS is not your friend. I agree about CVS' limitations completely. I know that a lot of Linux projects are under their own CVS control but what kind of history is available for code once it reaches Linus? Does Linus have a CVS repository which stores file-by-file history for the kernel? -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
I agree about CVS' limitations completely. I know that a lot of Linux projects are under their own CVS control but what kind of history is available for code once it reaches Linus? Does Linus have a CVS repository which stores file-by-file history for the kernel? No. That's what Bitkeeper and some of the retroactive release stream reconstruction that Larry's been doing is about. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
On Sat, 1 May 1999, Matthew Jacob wrote: I agree about CVS' limitations completely. I know that a lot of Linux projects are under their own CVS control but what kind of history is available for code once it reaches Linus? Does Linus have a CVS repository which stores file-by-file history for the kernel? No. That's what Bitkeeper and some of the retroactive release stream reconstruction that Larry's been doing is about. That sounds like it would be time well spent. I like the sound of Bitkeeper a lot. I just want someone else to test it :-). -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
That sounds like it would be time well spent. I like the sound of Bitkeeper a lot. I just want someone else to test it :-). You and everyone else! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
Look- if Linux adopts Bitkeeper, you really should pay attention to that. I doubt you'd find a more difficult set of software engineers to keep code in sync for than the Linux folks- if Bitkeeper works for them and essentially makes a rational release train for Linux, then a major glaring flaw in Linux' strategy that keeps serious businesses from really being able to trust it will be removed. Think about it. I think this all fails to address the distribution problem, however. Let's say we adopt bitkeeper - what becomes of CTM, CVSup and CVSWeb, all interfaces in extremely common use today? It's not just enough to say something will be worked out as an answer either, not when contemplating a move which will remove services currently in heavy operational use. Think about it. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
Look- if Linux adopts Bitkeeper, you really should pay attention to that. I doubt you'd find a more difficult set of software engineers to keep code in sync for than the Linux folks- if Bitkeeper works for them and essentially makes a rational release train for Linux, then a major glaring flaw in Linux' strategy that keeps serious businesses from really being able to trust it will be removed. Think about it. I think this all fails to address the distribution problem, however. Let's say we adopt bitkeeper - what becomes of CTM, CVSup and CVSWeb, all interfaces in extremely common use today? It's not just enough to say something will be worked out as an answer either, not when contemplating a move which will remove services currently in heavy operational use. Think about it. :) I'll try, but it hurts my head (Why, Ale, man! Ale's the stuff to drink, for them whom it hurts to think!...) I wasn't suggesting that we jump..I would like to see a plan. I believe BitKeeper and other tools are a good set of tools for the next 5-10 years for *development*. *Distribution* is a separate issue. Again, CVS is a fine tool for distribution and asymmetric (biased toward a higher level of outbound source changes) development. It all depends on what we want. And I'll have to admit that distribution of binaries source is not something that always is on the top of my list (well, *I'm* not working for a software distribution company...:-)).. My comment about 'think about it' is that if Linux gets it's chaotic source non-management corrected and is able to successfully coordinate all the relatively anarchic and free running clock different groups then the 'predictability and reproducibility' concerns of commercial buyers are closer to being met (which is silly because of how really chaotic internal company release spasms are, SGI being a notorious example- but there it is). If FreeBSD (and NetBSD and OpenBSD) are to continue the way it is now, CVS is probably a good enough tool. However, if you incorporate something like BitKeeper into the picture, then it actually becomes technically more feasible to even begin *considering* a *BSD coordination- you start to have to toolset that can manage large amounts of code that is mostly alike but differs in enough ways to be too hard to just merge this week. But then again you might say, Pshaw- Matt's been smokin' some serious rope again. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
Well, I'm not philosophically opposed to a clearly superior solution, I simply don't want to see us make any moves which involve so many messy trade-offs that we end up wasting more time embroiled in debate than we save with the new tool. My suggestion would be to wait and see how bitkeeper pans out. Enough people in the Linux camp have already looked at CVSup and gone ooh, sexy! that I think there will already be significant pressure to develop similar tools for the bitkeeper environment. When that happens, we can start to look at this more seriously. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
Well, I'm not philosophically opposed to a clearly superior solution, I simply don't want to see us make any moves which involve so many messy trade-offs that we end up wasting more time embroiled in debate than we save with the new tool. My suggestion would be to wait and see how bitkeeper pans out. Enough people in the Linux camp have already looked at CVSup and gone ooh, sexy! that I think there will already be significant pressure to develop similar tools for the bitkeeper environment. When that happens, we can start to look at this more seriously. Well, that's fine too, then... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
According to Matthew Jacob: Bitkeeper is a substantial improvement over CVS and Perforce. It's really WHat are the improvements compared to Perforce ? I've begun looking at it and if we forgot the Open Source argument (one that the FreeBSD project can't forget), it is really a very nice SCM. They even give free licenses to people writing/maintaining free software. I know, I just got mine. User name: roberto Client name: dotfiles Client root: /users/staff/roberto Current directory: /tmp Client address: 193.56.58.65:2838 Server address: keltia.freenix.fr:1666 Server root: /work/p4home Server version: P4D/FREEBSD/99.1/10314 (1999/03/31) Server license: Robert Ollivier robe...@eurocontrol.fr 10 users on freebsd (support ends 2000/04/26) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #2: Fri Apr 16 22:37:03 CEST 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
According to Harlan Stenn: I'm mostly interested in the lines of development features, the ability to check in various revisions of my *local* work, the ability to apply a patch set as an atomic unit, and several of the GUI tools. Perforce has all that. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #2: Fri Apr 16 22:37:03 CEST 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
Oh, very well, I'll have to say Perforce isn't that bad- it's just that it doesn't have a snappy set of tcl/tk GUI tools that allow you look at whole branch and revision histories.. It doesn't have a 3-way filemerge tool (I still fire up teamware (what NSElite became) to do heavy merging and use the automerge feature)... Perforce *does* have the disparate release stream feature, but I have found it somewhat difficult to use. Perhaps if I'd actually had the depot locally I'd feel more at home with it Bitkeeper is a substantial improvement over CVS and Perforce. It's really WHat are the improvements compared to Perforce ? I've begun looking at it and if we forgot the Open Source argument (one that the FreeBSD project can't forget), it is really a very nice SCM. They even give free licenses to people writing/maintaining free software. I know, I just got mine. User name: roberto Client name: dotfiles Client root: /users/staff/roberto Current directory: /tmp Client address: 193.56.58.65:2838 Server address: keltia.freenix.fr:1666 Server root: /work/p4home Server version: P4D/FREEBSD/99.1/10314 (1999/03/31) Server license: Robert Ollivier robe...@eurocontrol.fr 10 users on freebsd (support ends 2000/04/26) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #2: Fri Apr 16 22:37:03 CEST 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
The folks who did BitKeeper have a compare/contrast section in their web page that talks about BitKeeper vs. CVS and Perforce. http://www.bitkeeper.com I'm running CVS at several places, and I'm going to try BitKeeper for a couple of projects. H To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: solid NFS patch #6 avail for -current - need testers files)
-Original Message- From: Doug Rabson [mailto:d...@nlsystems.com] Sent: 21 April 1999 20:14 To: Matthew Dillon Cc: Peter Wemm; Matthew Reimer; freebsd-current@freebsd.org Subject: Re: solid NFS patch #6 avail for -current - need testers files) I wonder if it would be too radical to suggest that the release cycle for 4.0 be *much* shorter than the 3.0 cycle. Maintaining two branches gets worse and worse as time goes on and it just becomes a waste of programmer time. If we are reasonably careful with the 4.0 tree, I think a 4.0 release could be branched off it after 3.2 or maybe 3.3. It seems to me that merging a complex set of changes (such as the VM fixes or the new-bus work) from 4.0 to the 3.x branch would tend to produce a system which was less stable than the 'natural' environment for the software which is being merged across. I wonder if it would be too radical to suggest a third branch :-) I know of an increasing number of people who are not tracking -stable anymore because it's losing its reputation of stability. The main reason being that changes are pushed across from -current with little or no testing in -stable. I think -stable should have very conservative commit rules, only bug fixes, no feature creap. For the commercial users this is what they want, they're not interested in the newer features, they want what they already to have to work more reliably. There is however a more vocal group of people who chase features and they adhere to the rules and don't run -current to get them but increasingly their pressure has meant that -current features are hitting -stable very quickly. I think there should be three branches: 1) -current, usual rules apply, may toast your box at any moment, don't use unless you're prepared for such eventualities. 2) -beta, the place where new features migrate from -current when they seem to be working ok. Still potentially flakey but isn't expected to toast your machine. Users need to put up with problems but it should be an useable platform for a lot of people. It gets new features quickly. 3) -stable, only changes made to this branch are bug fixes, no new features added ever. I think -current has largely become -beta with the problem that when it does hit bad spots the beta users complain far too loudly than they really have the right to. The user base should be shifted as follows 1) -current has very few (relatively) users, only those developers who work on the OS (i.e. not ports) code. 2) The vast majority of people who run -current at the moment should really be running -beta. 3) -stable is for those who don't track FreeBSD. They upgrade only when a release takes place and not even at every release. These are mostly commercial users or home users who really aren't into the OS and just want a working box. In terms of workload I don't think it would have the major impact that people fear. Merges back to -stable should be *very* rare and so should not amount to any significant workload. Most of the merges we do to -stable at the moment should really be done to -beta so the workload there would be the same. Possibly even more radical than a third branch Change the -current list into -beta and form a new -current list that requires signing (figuratively not literally) an agreement that you accept -current may seriously hose you. Only allow people who have agreed these terms to post to the list, it would still be open for everyone to follow. This should reduce the number of whining messages on the development list from people who shouldn't really be running the development branch. Paul Richards Originative Solutions Ltd. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: solid NFS patch #6 avail for -current - need testers files)
Hello, My name is David DeTinne and I have been suscribing to FreeBSD Stable for some time now, before 2.2.2 was released. Here is my view regarding your posting: 3.1 is probably the most unstable stable version ever to be sent out by Walnut Creek. I have a machine that has 2.2.6 on it, which has been abused, cold booted, etc. When I received 3.1 in the mail I installed it on three seperate machines before giving up. to many system failures. I am waiting for 3.2 to replace my 2.2.6 installation due to the machine's importance. Right now I am using 4.0 current 19990421 on my test box which works fine, go figure? Although I am not a programmer, I do care about the open source movement, and look forward to the day where I can replace all of the desktop OS's in my office with a free version of unix, linux, etc. To sum it all up is there any difference between the branches? Thank You, David DeTinne To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
To sum it all up is there any difference between the branches? Yes. We hope that people like you will help us by participating in the testing of potential releases _before_ they go out as releases, not _afterwards_. Sitting around doing nothing and then complaining after the fact doesn't help anyone, least of all yourself. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: solid NFS patch #6 avail for -current - need testers files)
On Fri, 30 Apr 1999 da...@aps-services.com wrote: 3.1 is probably the most unstable stable version ever to be sent out by Walnut Creek. I have a machine that has 2.2.6 on it, which has been abused, cold booted, etc. When I received 3.1 in the mail I installed it on three seperate machines before giving up. to many system failures. I am waiting for 3.2 to replace my 2.2.6 installation due to the machine's importance. use 3.1-stable from current.freebsd.org last -stable is TODAY-stable :-)) Right now I am using 4.0 current 19990421 on my test box which works fine, go figure? time-to-time -current in some features is MORE stable then last -STABLE, but -current is CURRENT: its a development version. Although I am not a programmer, I do care about the open source movement, and look forward to the day where I can replace all of the desktop OS's in my office with a free version of unix, linux, etc. To sum it all up is there any difference between the branches? plz c handbook at http://www.freebsd.org/handbook Rgdz, Sergey A. Osokin, o...@etrust.ru To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
To sum it all up is there any difference between the branches? Yes. We hope that people like you will help us by participating in the testing of potential releases _before_ they go out as releases, not _afterwards_. Sitting around doing nothing and then complaining after the fact doesn't help anyone, least of all yourself. This isn't meant in a bad way, but let me share with you my experiences. Before 3.0 was released, I said several times Hey, NFS got a lot worse on -CURRENT. Is anyone looking at this? and got several replies of Duh, this is -CURRENT. Don't whine about it. If you're trying to use this in a production environment, you're crazy. After 3.0 was released, I said Hey, 3.0 got released, and NFS was still broken, to which I got Why didn't you bug us about this before the release? and/or Why didn't you test this before release? I understand NFS is a 'special' problem, but for those of us not in the trenches coding, I think the '3-level' system would be better. -CURRENT for those who are coding, -BETA for people like me to test things and bring up what broke, and -RELEASE for everyone else. I honestly don't know when to bring up things like that, now. :) Kevin To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
I honestly don't know when to bring up things like that, now. :) For 3.2, _right_now_. What you're doing with Matt is the first stage; the next involves bringing it back to the 3.2-beta tree and testing it there. Please understand that if you (the community) aren't working on this, nobody else is. We don't have enough people manning the trenches because they're all sitting back in the chateau waiting for the afternoon dispatches. This doesn't work. 8) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
On Fri, 30 Apr 1999, Mike Smith wrote: To sum it all up is there any difference between the branches? Yes. We hope that people like you will help us by participating in the testing of potential releases _before_ they go out as releases, not _afterwards_. Sitting around doing nothing and then complaining after the fact doesn't help anyone, least of all yourself. I seem to recall that there was a lot of noise about the instability of 3 before it was released, but that it went out the door because it had been taking too long. Wasn't it Greg Lehey who said that the beta period seemed more like integration testing? Ben You have your mind on computers, it seems. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
Brian Feldman wrote: I just wish april would go away, very, very fast... Here's a challenge to help you get by the rest of the days, figure out how to write my name, in its original form I was given at birth :-) Hmm... is it cheating to use Hiragana? (^_^) Being a chinese name (I think -- not a japanese one, for sure), I don't think it will help. Besides, you can't spell an L in hiragana. :-) My own take is (japanese characters -- sorry, no chinese input) 陳 for Chen. For Luoqi, japanese shift-jis/euc-jp just won't do. Well, I cheated, anyway... -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org Well, Windows works, using a loose definition of 'works'... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
Previously on Wed, Apr 21, 1999 at 12:31:03PM -0700, Matthew Dillon wrote: : : I think the existing release schedule is pretty good. Any faster and : we might as well not have two branches at all. We really need a : -current branch in order to make and test radical changes, and the : companies people who use FreeBSD need a -stable branch to keep : production boxes up to date without having to bet the farm. : : We already have the ability to shortcut certain things simply by : copying them from -current to -stable wholesale after we've determined : their stability under -current. The issue here really is safety. I : know some of you really want some of the things in -current to be : backported into -stable more quickly, but you have to be patient. We : can't compromise -stable's stability by acting too quickly. : Speaking as a heavy stable user and also a Net and OpenBSD user the big selling point I have for using FreeBSD over the other 'free' BSDs, Linux and some commercial OSs is the release structure. I believe radical alterations to this structure would be best avoided. It is only post 3.1 release that I have become confident in the RelEng3 branch as a service platform. People desperate for current functionality can wait, back port themselves or run current. I have taken all three options in the past :-) -- GeoffB To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
This is the only thing stopping me from upgrading our production machines to 3.1-STABLE. Please, please, please backport these fixes! I have to echo these feelings. NFS, as both server and client, is working without noticeable problems for us under the old 2.2-stable. I am afraid of upgrading to 3.1-stable with the reported NFS problems, and we can't get by without NFS. Some serious consideration should be given to fix the NFS problems in 3.1 - at least to make it more reliable. Perhaps there can be well announced unstable periods of -stable for things like merging non-trivial changes from -current? Dan Eischen eisc...@vigrid.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
People desperate for current functionality can wait, back port themselves or run current. I have taken all three options in the past :-) I agree. I have recently installed 3.1-STABLE on two machines, and in each case the ethernet drivers (xl and lnc) had been broken since 3.1 (both are now fixed). Stable is already not stable enough! -- Richard To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
On Thu, 22 Apr 1999, Daniel Eischen wrote:
I have to echo these feelings. NFS, as both server and client, is
working without noticeable problems for us under the old 2.2-stable.
I am afraid of upgrading to 3.1-stable with the reported NFS problems,
and we can't get by without NFS.
I was refering to the find/grep problem - I tried to start a thread in
sta...@freebsd.org...
Dan Eischen
eisc...@vigrid.com
--
:{ an...@speednet.com.au
Andy Farkas
System Administrator
Speed Internet Services
http://www.speednet.com.au/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
Steve Kargl wrote: That's a little foolish since we've still not found all the egcs optimizer bugs and whatnot; didn't you guys see the one Luigi found the other day for ftpd? Now *that* had to be some obscure debugging work! :-) Clearly, that goes to show Luigi must have no life... :-) Luigi is an interesting spelling of Louqi. To my defense, I thought it was Louqi, but since I have been making a lot of mistaken comments lately, I decided to trust what Jordan has said... I just wish april would go away, very, very fast... -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org Well, Windows works, using a loose definition of 'works'... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
Steve Kargl wrote: That's a little foolish since we've still not found all the egcs optimizer bugs and whatnot; didn't you guys see the one Luigi found the other day for ftpd? Now *that* had to be some obscure debugging work! :-) Clearly, that goes to show Luigi must have no life... :-) Luigi is an interesting spelling of Louqi. To my defense, I thought it was Louqi, but since I have been making a lot of mistaken comments lately, I decided to trust what Jordan has said... I thought you guys had better things to do other than arguing about how to spell my name. None of them is correct anyway, it is not even in alphabets... I just wish april would go away, very, very fast... Here's a challenge to help you get by the rest of the days, figure out how to write my name, in its original form I was given at birth :-) -- Daniel C. Sobral (8-DCS) d...@newsguy.com d...@freebsd.org Well, Windows works, using a loose definition of 'works'... -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
On Thu, 22 Apr 1999, Luoqi Chen wrote: Steve Kargl wrote: That's a little foolish since we've still not found all the egcs optimizer bugs and whatnot; didn't you guys see the one Luigi found the other day for ftpd? Now *that* had to be some obscure debugging work! :-) Clearly, that goes to show Luigi must have no life... :-) Luigi is an interesting spelling of Louqi. To my defense, I thought it was Louqi, but since I have been making a lot of mistaken comments lately, I decided to trust what Jordan has said... I thought you guys had better things to do other than arguing about how to spell my name. None of them is correct anyway, it is not even in alphabets... I just wish april would go away, very, very fast... Here's a challenge to help you get by the rest of the days, figure out how to write my name, in its original form I was given at birth :-) Hmm... is it cheating to use Hiragana? (^_^) -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org Well, Windows works, using a loose definition of 'works'... -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \ _ \ |) | http://www.freebsd.org _ |___)___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Alright, who's the smart alleck that fixed NFS this last week? :) , WAS: Re: solid NFS patch #6 avail for -current - need testers files)
On Tue, 20 Apr 1999, Matthew Dillon wrote: NFS patch #6 is now available for -current. This patch has been extensively tested with NFS and with FFS+softupdates and has not screwed up yet, so I'm reasonably confident that it will not scrap whole filesystems :-) http://www.backplane.com/FreeBSD4/ Please remember to back-out all prior patches before applying this one. Note that the memory-zeroing code ( which is committed to -current ), is *correct* and should not be disabled. This patch is for CURRENT ONLY. Do not apply to -3.x unless you like seeing computer equipment melt! The only difference between patch #5 and patch #6 is that the VMIO directory backing mods have been removed. These mods worked, but appear to have resulted in an occassional softupdates panic during 'installworld'. It is more important for us to have a rock solid implementation then majorly optimized implementation, so... The patch will probably return later on when we figure out why it is causing softupdates to panic. Please post bug reports to -current or -hackers. .(14:57:37)(r...@thumper.reserved) /usr # mount /dev/da0s1a on / (local, soft-updates, writes: sync 598 async 27021) /dev/da0s1g on /home (local, soft-updates, writes: sync 25 async 679) /dev/da0s1f on /usr (local, soft-updates, writes: sync 738 async 42763) /dev/da0s1e on /var (local, soft-updates, writes: sync 106 async 1783) procfs on /proc (local) server:/usr/src on /usr/src server:/usr/obj on /usr/obj server:/home/ncvs on /home/ncvs /usr/src # for i in 1 2 3 4 5 6 ; do make world -j64 ; echo $i done.. ; done ../build.log nfs server server:/usr/obj: not responding nfs server server:/usr/obj: is alive again .(15:00:59)(r...@thumper.reserved) /usr # uptime 3:01PM up 6:55, 1 user, load averages: 1.72, 7.03, 7.34 .(15:01:47)(r...@thumper.reserved) /usr # grep ^[0-9] done build.log 1 done.. 2 done.. 3 done.. .(15:05:05)(r...@thumper.reserved) /usr # .(03:33:51)(r...@bright.reserved) /usr/obj # uptime 10:02AM up 14:40, 1 user, load averages: 0.18, 0.16, 0.14 yeah the clocks are not setup properly :) but otherwise i'm just gonna say HOLY SH*T you fixed NFS! :) Actually I just realized I'm not running nfsiod on the client, I just started up 8 of them (it's an SMP box). So far no problems. I'm using the default mount operations, as far as NFS server not responding messages, i have no clue, but the server is still up and i've seen that message happen when a lot of pressure is being put on an NFS server even though everything is fine. Normally i'd have client corruption and a rebooted server with both of them locked up sending out garbled RPC about now, but everything seems fine... great work! 2 questions I had: 1) you said you disabled partial writes that were causing these mmap() problems, they were causing problems because NFS had to muck with the structures directly in order to do zero copy? so if our NFS impelementation didn't do that it wouldn't be an issue probably. I know it's a good thing for speed and definetly essensial, but i'm not sure i understand NFS and the FS getting out of sync. 2) at BAFUG 2 or 3 months ago I, *cough* attempted to keep up with you an Julian talking about VM issues. :) Something you guys brought up was problems with mmap() + read()/write() no staying in sync and requireing an msync() to correctly syncronize. I really didn't understand how this could happen except recently I figured that my first question could be the answer. Does this problem only happen on NFS mounted dirs? Is it fixed? thanks again, -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
Great work guys! It almost seems that -current is more stable than -stable! Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Alright, who's the smart alleck that fixed NFS this last week? :) , WAS: Re: solid NFS patch #6 avail for -current - need testers files)
:2 questions I had: : :1) you said you disabled partial writes that were causing these :mmap() problems, they were causing problems because NFS had to :muck with the structures directly in order to do zero copy? : so if our NFS impelementation didn't do that it wouldn't be :an issue probably. I know it's a good thing for speed and definetly :essensial, but i'm not sure i understand NFS and the FS getting out :of sync. The problem w/ the partial writes has to do with cache coherency between the server, the client's VFS subsystem ( read() and write() ), and the client's VM subsystem ( mmap() ). NFS implemented the notion of unaligned valid and dirty range using struct buf's b_validoff, b_validend, b_dirtyoff, and b_dirtyend fields in order to keep track of partial writes without having to read-in the rest of the buffer. The implementation was very fragile and failed to address a number of combination situations that would occur with mmap(), read(), and write(). This in turn lead to a series of problems and, further, lead to the situation where we would fix unrelated bugs in the VM system and cause NFS to break. I finally gave up on it. What NFS does now is optimize only two write situations: (1) when a write covers the entire buffer, e.g. an 8K+ write on an 8K boundry. And (2) piecemeal writes in the write-append case. Both cases allow us to mark the buffer as essentially being fully valid without having to mess with valid and dirty ranges. We use buf-b_bcount to handle the file EOF case and resize it rather then try to use b_validoff/b_validend. Thus, b_validoff/b_validend have been completely removed. b_dirtyoff/b_dirtyend have been left intact in order to allow us to support piecemeal write RPC's. This is different from the piecemeal write optimizations we were doing before. In this case, we are able to support piecemeal writes in the middle of the file that go into *PRELOADED* buffers. That is, A read-merge-write case. The original code attempted to do piecemeal writes without the read-before resulting in the partially invalid, partially dirty buffer. Now we only allow piecemeal writes to occur in fully-valid buffers. While we could theoretically discard the dirty range and simply writeback the entire buffer when a modification is made to part of it, we keep the dirty range in order to *only* write the portion of the buffer that the explicit write() covered. This is done for cache coherency reasons. For example, take the situation where two different client machines do a seek/write to different portions of the same server-backed NFS file, where the two areas abut each other. Say one client writes 2 bytes at seek offset 10 and the second client writes 2 bytes at seek offset 12. As long as the areas are not overlapping, we want this type of operation to work properly and not scramble the data on the server even if the client's idea of the state of the date is not coherent. :2) at BAFUG 2 or 3 months ago I, *cough* attempted to keep up with you :an Julian talking about VM issues. :) Something you guys brought up :was problems with mmap() + read()/write() no staying in sync and requireing :an msync() to correctly syncronize. I really didn't understand how this :could happen except recently I figured that my first question could be :the answer. Does this problem only happen on NFS mounted dirs? Is it :fixed? : :thanks again, :-Alfred This should not be an issue any more for either UFS or NFS. If people find that it is an issue, there's a bug somewhere that needs to be addressed. This *was* an issue for NFS prior to the patch set. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
Matthew Reimer wrote: Great work guys! It almost seems that -current is more stable than -stable! Matt Funny you should mention it. I've heard this from a number of people over the last week.. One has even suggested using a particular known-good 4.0 snapshot in preference to a 3.1-stable for a production system.. Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Alright, who's the smart alleck that fixed NFS this last week? , :) , WAS: Re: solid NFS patch #6 avail for -current - need testers , files)
On Wed, 21 Apr 1999, Matthew Dillon wrote: :2 questions I had: : :2) at BAFUG 2 or 3 months ago I, *cough* attempted to keep up with you :an Julian talking about VM issues. :) Something you guys brought up :was problems with mmap() + read()/write() no staying in sync and requireing :an msync() to correctly syncronize. I really didn't understand how this :could happen except recently I figured that my first question could be :the answer. Does this problem only happen on NFS mounted dirs? Is it :fixed? : :thanks again, :-Alfred This should not be an issue any more for either UFS or NFS. If people find that it is an issue, there's a bug somewhere that needs to be addressed. This *was* an issue for NFS prior to the patch set. Ok, so is this what you and Julian were discussing about coherency issues? And it is fixed... cool. :) -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
Peter Wemm once wrote: Great work guys! It almost seems that -current is more stable than -stable! Funny you should mention it. I've heard this from a number of people over the last week.. One has even suggested using a particular known-good 4.0 snapshot in preference to a 3.1-stable for a production system.. Speaking of, when can we expect to see this wonderfull _stability_ improvement in -stable? I'm setting up a server here, and would rather have fixed NFS code in it... Yet, jumping to -current is officially wrong... Thanks! -mi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
:Matthew Reimer wrote: : Great work guys! It almost seems that -current is more stable than : -stable! : : Matt : :Funny you should mention it. I've heard this from a number of people over :the last week.. One has even suggested using a particular known-good 4.0 :snapshot in preference to a 3.1-stable for a production system.. : :Cheers, :-Peter I think that people should stick with 3.x unless there is something in -current that they really need such as the fixed NFS. current's core is very solid now and getting better, but a lot of the peripheral stuff has undergone rapid change. The new bus structure, the new compiler, the kernel build setup, configuration changes, and so forth. It's hard to keep up with it. I expect it will settle down in the next month or so. Most of the bug fixes have been backported to -stable. Getting the new VM system into -stable ( which I want to do just after the 3.2 release ) is going to require brute force, though. Unfortunately, the most recent fixes to NFS fall into that category so NFS-centric installations may need to use -current. :To Unsubscribe: send mail to majord...@freebsd.org :with unsubscribe freebsd-current in the body of the message : -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
On Thu, 22 Apr 1999, Peter Wemm wrote: Matthew Reimer wrote: Great work guys! It almost seems that -current is more stable than -stable! Matt Funny you should mention it. I've heard this from a number of people over the last week.. One has even suggested using a particular known-good 4.0 snapshot in preference to a 3.1-stable for a production system.. Cheers, -Peter And on this note -- is it planned to merge or backport these patches to -stable? We make very heavy use of NFS (udp, 100mb fxp0 fullduplex). We're using FreeBSD-3.1-STABLE as NFS clients to a big Auspex NS7000 NFS file server. We're in production mode in our lab and can't risk running -current on many of our machines so we've decided to run -stable on ALL of them (except perhaps MY machine but don't tell anyone ;-) Tom To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
Matthew Reimer wrote: Great work guys! It almost seems that -current is more stable than -stable! Matt Funny you should mention it. I've heard this from a number of people over the last week.. One has even suggested using a particular known-good 4.0 snapshot in preference to a 3.1-stable for a production system.. Cheers, -Peter Are there any particularly good snapshots one should try? I have a couple of spare boxes on the home net that I am willing to try or crash, for the fun of it. I was using the snap from about 3 weeks back on my home web server and it seems rock solid, but I am running rather plain hardware. Bob Keys To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
On Wed, 21 Apr 1999, Matthew Dillon wrote: :Matthew Reimer wrote: : Great work guys! It almost seems that -current is more stable than : -stable! : : Matt : :Funny you should mention it. I've heard this from a number of people over :the last week.. One has even suggested using a particular known-good 4.0 :snapshot in preference to a 3.1-stable for a production system.. : :Cheers, :-Peter I think that people should stick with 3.x unless there is something in -current that they really need such as the fixed NFS. current's core is very solid now and getting better, but a lot of the peripheral stuff has undergone rapid change. The new bus structure, the new compiler, the kernel build setup, configuration changes, and so forth. It's hard to keep up with it. I expect it will settle down in the next month or so. Most of the bug fixes have been backported to -stable. Getting the new VM system into -stable ( which I want to do just after the 3.2 release ) is going to require brute force, though. Unfortunately, the most recent fixes to NFS fall into that category so NFS-centric installations may need to use -current. I wonder if it would be too radical to suggest that the release cycle for 4.0 be *much* shorter than the 3.0 cycle. Maintaining two branches gets worse and worse as time goes on and it just becomes a waste of programmer time. If we are reasonably careful with the 4.0 tree, I think a 4.0 release could be branched off it after 3.2 or maybe 3.3. It seems to me that merging a complex set of changes (such as the VM fixes or the new-bus work) from 4.0 to the 3.x branch would tend to produce a system which was less stable than the 'natural' environment for the software which is being merged across. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
:I wonder if it would be too radical to suggest that the release cycle for :4.0 be *much* shorter than the 3.0 cycle. Maintaining two branches gets :worse and worse as time goes on and it just becomes a waste of programmer :time. If we are reasonably careful with the 4.0 tree, I think a 4.0 :release could be branched off it after 3.2 or maybe 3.3. : :It seems to me that merging a complex set of changes (such as the VM fixes :or the new-bus work) from 4.0 to the 3.x branch would tend to produce a :system which was less stable than the 'natural' environment for the :software which is being merged across. : :-- :Doug RabsonMail: d...@nlsystems.com :Nonlinear Systems Ltd. Phone: +44 181 442 9037 I think the existing release schedule is pretty good. Any faster and we might as well not have two branches at all. We really need a -current branch in order to make and test radical changes, and the companies people who use FreeBSD need a -stable branch to keep production boxes up to date without having to bet the farm. We already have the ability to shortcut certain things simply by copying them from -current to -stable wholesale after we've determined their stability under -current. The issue here really is safety. I know some of you really want some of the things in -current to be backported into -stable more quickly, but you have to be patient. We can't compromise -stable's stability by acting too quickly. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
On 21-Apr-99 Matthew Dillon wrote: Most of the bug fixes have been backported to -stable. Getting the new VM system into -stable ( which I want to do just after the 3.2 release ) is going to require brute force, though. Unfortunately, the most recent fixes to NFS fall into that category so NFS-centric installations may need to use -current. -Matt Matthew Dillon dil...@backplane.com I'm curious, is there any plan to backport egcs to -stable or no? Also, as a side note: good thing we went with egcs, as it was just announced that egcs is now the official gcc. --- John Baldwin jobal...@vt.edu -- http://members.freedomnet.com/~jbaldwin/ PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc Power Users Use the Power to Serve! - http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
On Wed, 21 Apr 1999, Matthew Dillon wrote: :I wonder if it would be too radical to suggest that the release cycle for :4.0 be *much* shorter than the 3.0 cycle. Maintaining two branches gets :worse and worse as time goes on and it just becomes a waste of programmer :time. If we are reasonably careful with the 4.0 tree, I think a 4.0 :release could be branched off it after 3.2 or maybe 3.3. : :It seems to me that merging a complex set of changes (such as the VM fixes :or the new-bus work) from 4.0 to the 3.x branch would tend to produce a :system which was less stable than the 'natural' environment for the :software which is being merged across. : :-- :Doug Rabson Mail: d...@nlsystems.com :Nonlinear Systems Ltd. Phone: +44 181 442 9037 I think the existing release schedule is pretty good. Any faster and we might as well not have two branches at all. We really need a -current branch in order to make and test radical changes, and the companies people who use FreeBSD need a -stable branch to keep production boxes up to date without having to bet the farm. We already have the ability to shortcut certain things simply by copying them from -current to -stable wholesale after we've determined their stability under -current. The issue here really is safety. I know some of you really want some of the things in -current to be backported into -stable more quickly, but you have to be patient. We can't compromise -stable's stability by acting too quickly. I totally agree about not wanting to compromise the stability of our release branch. However as the codebases diverge (and 3.0 diverged pretty massively from 2.2) it will get harder and harder to merge significant improvements across from the development branch without compromising the stability which we are trying to maintain. All I'm saying (I think) is that we shouldn't allow the 4.0 release cycle to stretch out to 2 years like the 3.0 cycle did (discounting 3.0 as a beta release). -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
:Speaking of, when can we expect to see this wonderfull _stability_ :improvement in -stable? I'm setting up a server here, and would :rather have fixed NFS code in it... Yet, jumping to -current is :officially wrong... Thanks! : : -mi Well, you already see a lot of the pure bug fixes being backported. What you don't see in -stable are the bug fixes that also depend on the rewritten portions of the system, nor do you see the rewritten portions of the system themselves. The latest NFS patch is borderline -- it would be possible to backport in time enough for the 3.2 deadline, but it wouldn't be fun. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
At 01:09 PM 4/21/99 -0700, Matthew Dillon wrote:
:Speaking of, when can we expect to see this wonderfull _stability_
:improvement in -stable? I'm setting up a server here, and would
:rather have fixed NFS code in it... Yet, jumping to -current is
:officially wrong... Thanks!
:
: -mi
Well, you already see a lot of the pure bug fixes being backported.
What you don't see in -stable are the bug fixes that also depend on the
rewritten portions of the system, nor do you see the rewritten portions
of the system themselves. The latest NFS patch is borderline -- it
would be possible to backport in time enough for the 3.2 deadline, but
it wouldn't be fun.
Hi,
Just wondering if these changes also have the side effect of fixing the
nmap problem that crashes 3.x boxes ? i.e. as you wrote back on 3/4/99
The problem is a deadlock caused by the fgrep. The fgrep is mmap()ing
the file, but then it does some really weird crap when dealing with
larger files.
It's the most idiotic code I've ever seen. The code uses a PRIVATE+RW
mmap() until it gets to odd point in the file, at which point it read()'s
additional information from the file into the mapped space ( that might
contain a previous mmap'd portion of the file ).
So what happens is this:
* read() call
* shared lock obtained on vnode
( some other process attempts to get shared lock on vnode and
succeeds... for example, a namei operation is attempted by
another grep )
* access MMAP'd area
* exclusive lock attempt obtained on same vnode. This blocks because
some other process has a shared lock on the vnode.
( the other process then attempts to get an exclusive lock on the
vnode this blocks.
Deadlock.
Even worse, the gnu grep does not bother munmap()'ing the space so, in
fact, the deadlock can occur between two unrelated files as well as with
the same file. This is the more likely deadlock scenario.
The solution is more difficult. We could hack an exception for PRIVATE
mmap's... there really is no need for the vm_fault code to lock the
vnode.
Howver, other situations can occur where this hack would not work.
This is 'kinda a known problem' in FreeBSD. We really need to find a
solution to it. Other similar deadlocks can occur if you mmap() one file
and read() or write() data from it to another file, and vise versa at
the same time.
Personally, I think the only real solution is to make vn_read() and
vn_write() lock the uio space as well as the vnode being read or
written. It would have to do it in the right order, and it would have
to deal with the situation where the uio space covers multiple vnodes.
Alternately, vnodes need to be redesigned without these fraggin
all-encompassing locks for data R+W ops.
-Matt
(kgdb) back
#0 mi_switch () at ../../kern/kern_synch.c:827
#1 0xf0151919 in tsleep (ident=0xf0a2e500, priority=0x8, wmesg=0xf0263a9c
inode, timo=0x0)
at ../../kern/kern_synch.c:443
#2 0xf014b774 in acquire (lkp=0xf0a2e500, extflags=0x140,
wanted=0x700) at ../../kern/kern_lock.c:145
#3 0xf014b835 in lockmgr (lkp=0xf0a2e500, flags=0x1030041,
interlkp=0xf51719b0, p=0xf5151200)
at ../../kern/kern_lock.c:209
#4 0xf0171df0 in vop_stdlock (ap=0xf5176b94) at ../../kern/vfs_default.c:210
#5 0xf0204b39 in ufs_vnoperate (ap=0xf5176b94) at
../../ufs/ufs/ufs_vnops.c:2309
#6 0xf017aba4 in vn_lock (vp=0xf5171940, flags=0x1030041, p=0xf5151200)
at vnode_if.h:811
#7 0xf01747b0 in vget (vp=0xf5171940, flags=0x1020041, p=0xf5151200) at
../../kern/vfs_subr.c:1348
#8 0xf0212f1e in vnode_pager_lock (object=0xf02af2b4) at
../../vm/vnode_pager.c:960
#9 0xf0206a56 in vm_fault (map=0xf51497c0, vaddr=0x805d000,
fault_type=0x3, fault_flags=0x8)
at ../../vm/vm_fault.c:243
#10 0xf022aebe in trap_pfault (frame=0xf5176d14, usermode=0x0,
eva=0x805d038) at ../../i386/i386/trap.c:816
#11 0xf022ab92 in trap (frame={tf_es = 0x10, tf_ds = 0x10, tf_edi =
0x805d000, tf_esi = 0xf223e000,
tf_ebp = 0xf5176e0c, tf_isp = 0xf5176d3c, tf_ebx = 0x1060, tf_edx =
0x0, tf_ecx = 0x700, tf_eax = 0x0,
tf_trapno = 0xc, tf_err = 0x3, tf_eip = 0xf0229ce4, tf_cs = 0x8,
tf_eflags = 0x10287, tf_esp = 0x1272,
tf_ss = 0x}) at ../../i386/i386/trap.c:437
#12 0xf0229ce4 in fastmove_loop ()
#13 0xf0229b2b in i586_copyout ()
#14 0xf01fd707 in ffs_read (ap=0xf5176ef0) at
../../ufs/ufs/ufs_readwrite.c:289
#15 0xf017a689 in vn_read (fp=0xf09dda80, uio=0xf5176f38, cred=0xf09ef480)
at vnode_if.h:303
#16 0xf015a757 in read (p=0xf5151200, uap=0xf5176f94) at
../../kern/sys_generic.c:121
#17 0xf022b4a0 in syscall (frame={tf_es = 0x2f, tf_ds = 0x2f, tf_edi =
0x0, tf_esi = 0x8000, tf_ebp = 0xefbf85c8,
tf_isp = 0xf5176fe4, tf_ebx = 0x, tf_edx = 0x8059000, tf_ecx
= 0xa, tf_eax = 0x3,
Re: solid NFS patch #6 avail for -current - need testers files)
:Hi, :Just wondering if these changes also have the side effect of fixing the :nmap problem that crashes 3.x boxes ? i.e. as you wrote back on 3/4/99 : : :The problem is a deadlock caused by the fgrep. The fgrep is mmap()ing :the file, but then it does some really weird crap when dealing with :larger files. : I believe this was fixed in -current. I don't know if it was backported to -stable. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
Speaking of upgrading to -current from 3.x-STABLE, I was just wondering -- does the new EGCS imply that things like apps2go Motif won't link properly against a 4.x-CURRENT world now? It's things like this that will hold me back, if they indeedy are a problem. Brian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
At 01:29 PM 4/21/99 -0700, Matthew Dillon wrote: :Hi, :Just wondering if these changes also have the side effect of fixing the :nmap problem that crashes 3.x boxes ? i.e. as you wrote back on 3/4/99 : : :The problem is a deadlock caused by the fgrep. The fgrep is mmap()ing :the file, but then it does some really weird crap when dealing with :larger files. : I believe this was fixed in -current. I don't know if it was backported to -stable. Unfortunately no... It can still lockup a 3.x machine. ---Mike Mike Tancsa, tel 01.519.651.3400 Network Administrator,m...@sentex.net Sentex Communications www.sentex.net Cambridge, Ontario Canada To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
Hi, At 4:34 pm -0700 20/4/99, Matthew Dillon wrote: NFS patch #6 is now available for -current.[etc] Looks real good here. Been running two servers continuously building the world with their /usr/obj cross-mounted on each other. Oh, and one of them is SMP running -j8. Great job! -- Bob Bishop (0118) 977 4017 international code +44 118 r...@gid.co.ukfax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
I'm curious, is there any plan to backport egcs to -stable or no? No. Also, as a side note: good thing we went with egcs, as it was just announced that egcs is now the official gcc. Yep, I had some inside info that this was probably going to happen. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
Funny you should mention it. I've heard this from a number of people over the last week.. One has even suggested using a particular known-good 4.0 snapshot in preference to a 3.1-stable for a production system.. That's a little foolish since we've still not found all the egcs optimizer bugs and whatnot; didn't you guys see the one Luigi found the other day for ftpd? Now *that* had to be some obscure debugging work! :-) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
Speaking of, when can we expect to see this wonderfull _stability_ improvement in -stable? I'm setting up a server here, and would Usually when we're sure it's not a pessimization in other ways. I think people are getting just a bit prematurely excited here, not to knock Matt's good work or anything but I think even he would be the last to jump up and down saying NFS is fixed! It's totally perfect now! as some younger, less wise heads are currently saying. :-) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
I wonder if it would be too radical to suggest that the release cycle for 4.0 be *much* shorter than the 3.0 cycle. Maintaining two branches gets worse and worse as time goes on and it just becomes a waste of programmer time. If we are reasonably careful with the 4.0 tree, I think a 4.0 What's your definition of much in this case? I also disagree that the multi-branch model is a waste of programmer time since it's what keeps us able to have an experimental line of development at all. To programmers, that's pretty important. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
I'm curious, is there any plan to backport egcs to -stable or no? Also, as a There are no plans at this time to merge egcs over. This will only happen if time and hindsight prove egcs to be of low enough impact that it's suitable -stable material. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
All I'm saying (I think) is that we shouldn't allow the 4.0 release cycle to stretch out to 2 years like the 3.0 cycle did (discounting 3.0 as a beta release). No argument there - the current schedule is 12 months for 4.0. 2 years far too long and merely the result of unforseen delays and more than a little paralysis over the issue. This caused a lot of soul-searching in core over our development practices, hopefully enough that we won't repeat that particular painful experience. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
Jordan K. Hubbard wrote: Funny you should mention it. I've heard this from a number of people over the last week.. One has even suggested using a particular known-good 4.0 snapshot in preference to a 3.1-stable for a production system.. That's a little foolish since we've still not found all the egcs optimizer bugs and whatnot; didn't you guys see the one Luigi found the other day for ftpd? Now *that* had to be some obscure debugging work! :-) Clearly, that goes to show Luigi must have no life... :-) -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org Well, Windows works, using a loose definition of 'works'... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
Daniel C. Sobral wrote: Jordan K. Hubbard wrote: Funny you should mention it. I've heard this from a number of people over the last week.. One has even suggested using a particular known-good 4.0 snapshot in preference to a 3.1-stable for a production system.. That's a little foolish since we've still not found all the egcs optimizer bugs and whatnot; didn't you guys see the one Luigi found the other day for ftpd? Now *that* had to be some obscure debugging work! :-) Clearly, that goes to show Luigi must have no life... :-) Luigi is an interesting spelling of Louqi. The bug was actually in libalias. -- Steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
Luigi is an interesting spelling of Louqi. Or even Luoqi, as his name is actually spelled. :-) Sorry, Mr. Chen, for the transposition of you and Luigi. Temporary brain fade! :) The bug was actually in libalias. Yes, also correct. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
: Speaking of, when can we expect to see this wonderfull _stability_ : improvement in -stable? I'm setting up a server here, and would : :Usually when we're sure it's not a pessimization in other ways. I :think people are getting just a bit prematurely excited here, not to :knock Matt's good work or anything but I think even he would be the :last to jump up and down saying NFS is fixed! It's totally perfect :now! as some younger, less wise heads are currently saying. :-) : :- Jordan NFS is definitely not fixed. NFS/TCP is still broken, the leasing stuff is still broken, and probably a bunch of other esoteric situations will cause breakage. There are still issues with stale file handles. There is no locking support ( however much NFS locking is a bad idea in general ). But it's *much* better then it was before'. The patch is certainly good enough to commit into -current. It is not commitable to -stable, though, because it depends on -current's VM VFS/BIO system. From my point of view, NFS/VM/VFS/BIO is now sitting where it *should* have been sitting a year ago if people had been paying more attention to it. If this were a Matt Dillon project, I would be sitting at my first 'beta' release :-( and everything up to this point would have been alpha. We have a long ways to go, folks. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
: work! :-) : : Clearly, that goes to show Luigi must have no life... :-) : : :Luigi is an interesting spelling of Louqi. : :The bug was actually in libalias. : :-- :Steve Luoqi found a bug in the compiler's optimizer. I presume someone has/will commit a change to libalias to work around it, and hopefully Luoqi notified the EGCS people. This sort of optimizer bug is usually fairly easy to fix given demonstration code, and Luoqi presented demonstration code. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
Matthew Dillon wrote: : work! :-) : : Clearly, that goes to show Luigi must have no life... :-) : : :Luigi is an interesting spelling of Louqi. Whoops! Luoqi ;-) :The bug was actually in libalias. : Luoqi found a bug in the compiler's optimizer. I presume someone has/will commit a change to libalias to work around it, and hopefully Luoqi notified the EGCS people. This sort of optimizer bug is usually fairly easy to fix given demonstration code, and Luoqi presented demonstration code. Luoqi committed a fix, but I don't remember if he fixed egcs or libalias. In his commit message, he states that he sent a bug report to the egcs people. -- Steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
:Just wondering if these changes also have the side effect of fixing the
:nmap problem that crashes 3.x boxes ? i.e. as you wrote back on 3/4/99
:
:The problem is a deadlock caused by the fgrep. The fgrep is mmap()ing
:the file, but then it does some really weird crap when dealing with
:larger files.
:
I believe this was fixed in -current. I don't know if it was backported
to -stable.
Unfortunately no... It can still lockup a 3.x machine.
This is the only thing stopping me from upgrading our production machines
to 3.1-STABLE.
Please, please, please backport these fixes!
--
:{ an...@speednet.com.au
Andy Farkas
System Administrator
Speed Internet Services
http://www.speednet.com.au/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
I was just wondering -- does the new EGCS imply that things like apps2go Motif won't link properly against a 4.x-CURRENT world now? My Apps2go Motif works just file post-EGCS. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
What does this patch fix? Tnks! Amancio -- Amancio Hasty ha...@star-gate.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
On Tue, 20 Apr 1999, Amancio Hasty wrote: What does this patch fix? NFS clients getting blocks of 0x00 in the cache. try to link a large object over NFS without the patches, you'll see what i mean. Matt, i'm going to test your patches now, I really appreciate the work and explanations you've given as to the problem and the solution you've devised. If anyone's gonna find a NFS bug :) I'm impressed with the changes you're proposing for the VM system and was wondering if these patches include the work for directory caching you've been working on. Thanks, -Alfred Tnks! Amancio -- Amancio Hasty ha...@star-gate.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
: :Matt, i'm going to test your patches now, I really appreciate the work :and explanations you've given as to the problem and the solution you've :devised. If anyone's gonna find a NFS bug :) : :I'm impressed with the changes you're proposing for the VM system :and was wondering if these patches include the work for directory :caching you've been working on. : :Thanks, :-Alfred No, we removed it temporarily while we track down a softupdates bug. Plus it's more an optimization ... not really a bug fix, so it should be separate. I didn't really propose that we do what I said in the last posting in re: to the VM system, though it is a possibility. Any changes at that level would not occur for a year or so ... not until 4.x becomes stable and 5.x becomes current. It wouldn't be worthwhile unless we could simplify some of the complexity in the existing setup, and there may be other ways to do that ( like, for example, embedding the I/O within the buffer cache routines rather then requiring that the caller issue the I/O, which encapsulates a great deal of the buffer cache's current complexity ). -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
:What does this patch fix? : : Tnks! : Amancio : : Amancio Hasty : ha...@star-gate.com It mainly fixes interactions between mmap(), read(), and write() on NFS files. Many utilities ( such as the compiler/linker ) these days use a combination of the three and NFS was making assumptions that would leave a VM page partially uncovered - where the NFS system is storing critical data in the page but the VM system didn't know it was. The mmap-zero fixes that were committed last week brought the problem to light. As part of the fix, a bunch of things were ripped out of the buffer cache code. For example, the b_validoff/b_validend fields were ripped out because only NFS previously used them ( but don't any more ). Also pieces of the buffer cache code were rewritten in regards to dealing with the B_CACHE bit, leading to more optimal code in the critical path ( fewer scans the the b_pages array when figuring out the B_CACHE state of a struct buf ). And some other stuff. The whole thing stems from fixes made to -current over the last several months, fixes made by Luoqi, Alan, Julian, DG, and me. Luoqi concentrated on fixing up the vm_page_t valid/dirty handling and struct buf b_offset handling when dealing with small-block devices ( people may recall that this fixed, then broke, then fixed msdos floppy mounts that would occur after a ufs mount attempt, and also fixed CDROM panics ). The rest of us were working on a mmap-zeroing problem, NFS, and a mmap-garbage-after-file-EOF problem brought up by Tor. A number of vnode interlock issues came up that we fixed, a getnewbuf() supervisor stack overflow was fixed (I rewrote getnewbuf()), a bunch of low-memory handling issues were dealt with but there are still a few left. A few minor bugs in softupdates were fixed with Kirk's help. A VNOP/MMAP deadlock was fixed. Tor DG and someone else threw in fixes for KVM exhaustion in large-memory subsystems, the ability to handle 2G of ram, and BSDI compatibility w/ the new KVM increase. Earlier this year I tackled basic bugs in the VM system, rewrote the swapper, rewrote the VN device, and formalized and documented most of the VM system, and Alan and I began removing unused cruft. All in all, it has been a good beginning to the year. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
