solid NFS patch #6 avail for -current - need testers files)

[Matthew Dillon]

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.

-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)

[Amancio Hasty]

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)

[Alfred Perlstein]

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)

[Matthew Dillon]

:
: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 




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]

: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 




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]

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: solid NFS patch #6 avail for -current - need testers files)

[Peter Wemm]

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: solid NFS patch #6 avail for -current - need testers files)

[Mikhail Teterin]

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 Dillon]

: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 




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)

[Tom Bartol]

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)

[rdkeys]

> 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)

[Doug Rabson]

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)

[Matthew Dillon]

: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 




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)

[John Baldwin]

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 
>   

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  -- 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)

[Doug Rabson]

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)

[Matthew Dillon]

: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 



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)

[Mike Tancsa]

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 = 0xf

Re: solid NFS patch #6 avail for -current - need testers files)

[Matthew Dillon]

: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)

[Brian Handy]

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)

[Mike Tancsa]

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)

[Bob Bishop]

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)

[David O'Brien]

> 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)

[Jordan K. Hubbard]

> 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)

[Jordan K. Hubbard]

> 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)

[Jordan K. Hubbard]

> 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)

[Jordan K. Hubbard]

> 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)

[Jordan K. Hubbard]

> 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)

[Daniel C. Sobral]

"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)

[Steve Kargl]

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)

[Jordan K. Hubbard]

> "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)

[Matthew Dillon]

:> 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 




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]

:> > 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 




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]

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)

[Andy Farkas]

> >: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)

[David O'Brien]

> 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)

[Geoff Buckingham]

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)

[Daniel Eischen]

> 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)

[Richard Tobin]

> 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)

[Andy Farkas]

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)

[Daniel C. Sobral]

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)

[Luoqi Chen]

> 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)

[Brian Feldman]

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

Re: solid NFS patch #6 avail for -current - need testers files)

[Daniel C. Sobral]

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)

[paul]

> -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)

[david]

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)

[Mike Smith]

> 
> 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)

[oZZ!!!]

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)

[Kevin Day]

> > 
> > 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)

[Mike Smith]

> 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)

[Snob Art Genre]

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)

[Doug Rabson]

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)

[Kevin Day]

> > 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)

[Harlan Stenn]

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)

[Matthew Dillon]

: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 



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)

[paul]

> -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: solid NFS patch #6 avail for -current - need testers files)

[Doug Rabson]

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)

[Matthew Jacob]

> 
> > 
> > :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)

[Doug Rabson]

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)

[Matthew Jacob]

> 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)

[Doug Rabson]

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)

[Matthew Jacob]

> 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: RE: solid NFS patch #6 avail for -current - need testers files)

[Matthew Dillon]

:> 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 


: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)

[Steve Price]

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)

[Matthew Jacob]

> 
> # 
> #: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: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)

[Robert Watson]

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)

[Harlan Stenn]

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: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)

[Matthew Jacob]

> 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)

[Matthew Jacob]

> 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: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)

[Jordan K. Hubbard]

> 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)

[Matthew Jacob]

> > 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)

[Jordan K. Hubbard]

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)

[Matthew Jacob]

> 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)

[Ollivier Robert]

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  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)

[Ollivier Robert]

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)

[Matthew Jacob]

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  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)

[Harlan Stenn]

The folks who did BitKeeper have a "compare/contrast" section in their web 
page that talks about BitKeeper vs. CVS and Perforce.



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: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)

[Kenneth D. Merry]

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: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)

[Warner Losh]

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)

[Warner Losh]

In message  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)

[Peter Mutsaers]

>> "RW" == Robert Watson  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)

[Brian Behlendorf]

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)

[Chuck Robey]

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)

[John Polstra]

In article ,
Chuck Robey   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

Alright, who's the smart alleck that fixed NFS this last week? :) , WAS: Re: solid NFS patch #6 avail for -current - need testers files)

[Alfred Perlstein]

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: Alright, who's the smart alleck that fixed NFS this last week? :) , WAS: Re: solid NFS patch #6 avail for -current - need testers files)

[Matthew Dillon]

: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 





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)

[Alfred Perlstein]

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