headers
Richard Rauch | 1 Sep 2002 01:49
Favicon

Re: /rescue, crunchgen'ed?

(Sorry for the numerous typos in the original.  On reading it, I'm
appalled at myself.  (^&  Oh well...)

> > The former seems about like the dependancy on crunchgen, and elimites the
> > complexity of having two sets of binaries.
>
> While exploding the / partition size. Otherwise: fine. Maybe we should add

If space on / is a problem for so many, why do /home and /var reside on /
by default?  I have trouble believing that a cramped / is a serious issue.

I'm sure you can find a few machines for which this acttuall matters.
Crunchgen may be preferable for them.  They may even want their / to have
crunchgen binaries (from the numbers someone listed, I think that that
saves even more space than shared, yes?).  People in such "extreme"
environments will presumably want or need to do some extra work to get
things working anyway; a default setup that they can override (and which
doesn't actively impede them installing a working system) seems like the
appropriate response, to me.

> yet another make knob to generate uncrunched /rescue binaries for those that
> like it and have the space available? (No idea if this is easily implementable
> without making a big mess out of the /sbin and /bin makefiles)

Or, generate uncrunched /rescue and add a knob to *not* generate /rescue.
If people want, they can use the dynamic-linked root (or the old
static-linked root) as their sole setup.  Then the Makefile knob would be
"generate /rescue or not", which should be fairly simple.

I'm not sure how much it complicates things to make a crunchgen'ed /rescue
(Continue reading)

Permalink | Reply | 3 comments |
headers
David Laight | 1 Sep 2002 11:01
Picon

Re: NetBSD, solaris, acls, and nfs

> Your two best bets are:
> 
> 1) Solaris 8 (you'll need many patches.  You'll need to enable metadata
>    logging on the filesystems to get good performance.)
> 
> 2) Linux with XFS and all of the latest NFS patches (these are not
>    really integrated into the 2.4.xx kernels in a timely manner, and
>    you *do* want them).

IIRC there is acl support in Unixware 2 (and hence 7) and hence
whatever might be avaialable now.  At least for one filesystem type.

	David

--

-- 
David Laight: david <at> l8s.co.uk
Permalink | Reply | 0 comments |
headers
NetBSD source update | 1 Sep 2002 12:47
Picon

daily CVS update output


Updating src tree:
P src/crypto/dist/kame/racoon/kmpstat.c
P src/crypto/dist/openssl/apps/apps.h
P src/crypto/dist/openssl/crypto/cryptlib.h
P src/crypto/dist/openssl/crypto/bio/bss_bio.c
P src/crypto/dist/openssl/crypto/bn/bntest.c
P src/crypto/dist/openssl/crypto/cast/cast_lcl.h
P src/crypto/dist/openssl/crypto/conf/conf_api.c
P src/crypto/dist/openssl/crypto/rand/md_rand.c
P src/crypto/dist/openssl/crypto/rand/randfile.c
P src/crypto/dist/openssl/crypto/rsa/rsa_test.c
P src/crypto/dist/openssl/crypto/threads/mttest.c
P src/crypto/dist/openssl/crypto/threads/th-lock.c
P src/crypto/dist/openssl/ssl/ssl_cert.c
P src/crypto/dist/openssl/ssl/ssl_locl.h
P src/crypto/dist/openssl/ssl/ssl_task.c
P src/crypto/dist/openssl/ssl/ssltest.c
P src/distrib/notes/i386/hardware
P src/distrib/sets/lists/comp/mi
P src/distrib/sets/lists/comp/obsolete.mi
U src/distrib/sets/lists/xbase/md.macppc
P src/distrib/sets/lists/xbase/mi
P src/distrib/sets/lists/xbase4/mi
U src/distrib/sets/lists/xcomp/md.macppc
U src/distrib/sets/lists/xcomp4/md.macppc
U src/distrib/sets/lists/xfont/md.macppc
P src/distrib/sets/lists/xserver/md.macppc
P src/distrib/sets/lists/xserver4/md.macppc
P src/lib/libcrypto/Makefile
(Continue reading)

Permalink | Reply | 0 comments |
headers
Arto Selonen | 1 Sep 2002 13:01

build error: e_os.h: No such file

Hi!

Yesterday I also got this:

On Sat, 31 Aug 2002, Juergen Hannken-Illjes wrote:

> On Sat, Aug 31, 2002 at 09:49:44AM -0700, Hisashi T Fujinaka wrote:

> > /usr/src/tools/obj/tools.NetBSD-1.6G-i386/bin/i386--netbsdelf-gcc -O2  -Wall
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-format-y2k
-Werror  -I/usr/src/usr.bin/systat/../../usr.bin/vmstat -DSUPPORT_UTMP -DSUPPORT_UTMPX 
-I/usr/src/usr.bin/systat/../../usr.bin/who -DINET6 -DIPSEC -nostdinc -isystem /usr/include  -c /usr/src/usr.bin/systat/bufcache.c
> > cc1: warnings being treated as errors
> > In file included from /usr/src/usr.bin/systat/bufcache.c:45:
> > /usr/include/sys/buf.h:97: warning: `struct buf' declared inside parameter list
> > /usr/include/sys/buf.h:97: warning: its scope is only this definition or declaration, which is
probably not what you want.
> > *** Error code 1

Today, after the fix:
> Fixed in sys/sys/buf.h rev 1.54.

I'm getting this (added whitespace + multiline for readability):

dependall ===> libcrypto_idea
CC=/usr/obj/tools/bin/i386--netbsdelf-gcc /usr/obj/tools/bin/nbmkdep -a \
   -Dlibcrypto_idea -I. -I/fs/cvs/src/crypto/dist/openssl/crypto \
   -DOPENSSLDIR=\"/etc/openssl\" -DDSO_DLFCN -DHAVE_DLFCN_H \
   -I/fs/cvs/src/crypto/dist/openssl/crypto \
   -I/fs/cvs/src/crypto/dist/openssl/crypto/idea \
(Continue reading)

Permalink | Reply | 1 comment |
headers
itojun | 1 Sep 2002 13:23

Re: build error: e_os.h: No such file

>I'm getting this (added whitespace + multiline for readability):
>dependall ===> libcrypto_idea
>In file included from /fs/cvs/src/crypto/dist/openssl/crypto/evp/e_idea.c:62:
>/fs/cvs/src/crypto/dist/openssl/crypto/cryptlib.h:65: e_os.h: No such file or directory
>In file included from /fs/cvs/src/crypto/dist/openssl/crypto/evp/c_allc.c:60:
>/fs/cvs/src/crypto/dist/openssl/crypto/cryptlib.h:65: e_os.h: No such file or directory
>nbmkdep: compile failed.
>*** Error code 1

	lib/libcrypto_idea/Makefile revision 1.6 fixes this issue.

itojun
Permalink | Reply | 0 comments |
headers
John Nemeth | 2 Sep 2002 01:49
Picon
Favicon

Re: CVS commit: [netbsd-1-6] sharesrc/share/tmac

On Dec 18,  2:53pm, Luke Mewburn wrote:
} 
} Module Name:	sharesrc
} Committed By:	lukem
} Date:		Sun Sep  1 23:45:45 UTC 2002
} 
} Modified Files:
} 	sharesrc/share/tmac [netbsd-1-6]: doc-common
} 	syssrc/sys/conf [netbsd-1-6]: osrelease.sh
} 
} Log Message:
} now at RC3.  branch is locked down, ready for release.

     Hurray!

}-- End of excerpt from Luke Mewburn
Permalink | Reply | 0 comments |
headers
Matthew Orgass | 2 Sep 2002 04:14

Re: /rescue, crunchgen'ed?

On Sat, 31 Aug 2002, Richard Rauch wrote:

> I'm sure you can find a few machines for which this acttuall matters.
> Crunchgen may be preferable for them.  They may even want their / to have
> crunchgen binaries (from the numbers someone listed, I think that that
> saves even more space than shared, yes?).  People in such "extreme"
> environments will presumably want or need to do some extra work to get
> things working anyway; a default setup that they can override (and which
> doesn't actively impede them installing a working system) seems like the
> appropriate response, to me.

  The real question is, what do you gain by not crunching them?  If you
are afraid something will happen to /rescue, copy it.  You should be able
to make at least five copies in less space than the uncrunched version
would take, and this would be five complete copies of everything.  If you
are worried that it will suddenly stop working, run a boot or cron job to
test it.  Wasting space for no good reason is never a good policy, no
matter how much you have available.

  Note also that simply testing new /lib libraries before installing them
will prevent 90% of the problems that /rescue is needed for (or,
alternately, keeping a "last known good" copy of the libraries to use in
case the new libraries fail).  This can easily be done with the current
system.  An easy way to test a new linker on a running system would
prevent just about all of the rest (this would be a fairly simple script
that I imagine someone has already written).  A static binary that lets
you exec a binary with an alternate interpreter would allow you to recover
with a backup linker and libraries (and would let you use all system
binaries, not just a few).
(Continue reading)

Permalink | Reply | 2 comments |
headers
NetBSD source update | 2 Sep 2002 09:44
Picon

triweekly CVS update output


Updating release-1-4 src tree (netbsd-1-4):

Running the SUP scanner:
SUP Scan for release-1-4 starting at Mon Sep  2 00:21:31 2002
SUP Scan for release-1-4 completed at Mon Sep  2 00:21:37 2002

Updating release-1-5 src tree (netbsd-1-5):

Running the SUP scanner:
SUP Scan for release-1-5 starting at Mon Sep  2 00:34:11 2002
SUP Scan for release-1-5 completed at Mon Sep  2 00:34:30 2002

Updating release-1-6 src tree (netbsd-1-6):
P src/share/man/man4/ahc.4
P src/sys/arch/cobalt/conf/GENERIC
P src/sys/arch/cobalt/stand/installkernel/installkernel.sh
P src/sys/dev/ic/aic7xxx.c
P src/sys/kern/exec_aout.c
P src/sys/nfs/nfs_bio.c

Running the SUP scanner:
SUP Scan for release-1-6 starting at Mon Sep  2 00:43:56 2002
SUP Scan for release-1-6 completed at Mon Sep  2 00:44:34 2002
Permalink | Reply | 0 comments |
headers
NetBSD source update | 2 Sep 2002 12:45
Picon

daily CVS update output


Updating src tree:
P src/bin/dd/dd.c
P src/crypto/dist/openssl/crypto/opensslconf.h
P src/distrib/notes/common/xfer
P src/distrib/sets/lists/xserver/md.macppc
P src/distrib/sets/lists/xserver4/md.macppc
P src/lib/libc/arch/sh3/string/ffs.S
P src/lib/libc/sys/rasctl.2
P src/lib/libcrypto_idea/Makefile
P src/lib/libcrypto_rc5/Makefile
P src/sbin/ifconfig/ifconfig.8
P src/sbin/mount/Makefile
P src/sbin/pppoectl/pppoectl.8
P src/sbin/pppoectl/pppoectl.c
P src/share/man/man4/pppoe.4
P src/sys/arch/hpcmips/vr/mq200_vrip.c
P src/sys/arch/sh5/include/db_machdep.h
P src/sys/arch/sh5/include/frame.h
P src/sys/arch/sh5/sh5/cpu_switch.S
P src/sys/arch/sh5/sh5/db_disasm.c
P src/sys/arch/sh5/sh5/db_interface.c
P src/sys/arch/sh5/sh5/exception.S
P src/sys/arch/sh5/sh5/genassym.cf
P src/sys/arch/sh5/sh5/process_machdep.c
P src/sys/arch/sh5/sh5/trap.c
P src/sys/arch/sh5/sh5/vm_machdep.c
P src/sys/dev/hpc/hpcfb.c
P src/sys/dev/usb/umass_quirks.c
P src/sys/kern/init_main.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Juergen Hannken-Illjes | 2 Sep 2002 16:05
Picon
Picon
Favicon

New device buffer queue strategy

A new device buffer queue strategy is available for testing.

The current implementation of disksort (a min seek sort) doesn't perform
very well with long queues of outstanding requests. Especially with
softdeps this is a very common situation. As all requests are ordered the
read latency may become very high.

The new strategy keeps disksort for write-requests while read-requests are
put on a second queue with first-come first-serve strategy.
Read-requests are served before write-requests.

While the overall I/O performance is the same, the system becomes more
responsive under high I/O load.

To test this strategy:

- lookup the `bufq_alloc' call in your favorite disk driver:

  ! sys/dev/scsipi/sd.c: bufq_alloc(&sd->buf_queue, BUFQ_DISKSORT|BUFQ_SORT_RAWBLOCK);

- replace the BUFQ_DISKSORT argument by BUFQ_READ_PRIO.

  ! sys/dev/scsipi/sd.c: bufq_alloc(&sd->buf_queue, BUFQ_READ_PRIO|BUFQ_SORT_RAWBLOCK);

- recompile kernel and test.

Comments and improvements are welcome.
--

-- 
Juergen Hannken-Illjes - hannken <at> eis.cs.tu-bs.de - TU Braunschweig (Germany)
(Continue reading)

Permalink | Reply | 4 comments |

Gmane