Re: Journaled filesystem in CURRENT
On Wed, 25 Sep 2002 11:12:34 -0700 Brooks Davis [EMAIL PROTECTED] wrote: Does CURRENT support journaled filesystem ? There are not journaling file systems in current at this time. Efforts to port both xfs and jfs are underway. We have something better than those. SoftUpdates. Much faster than jfs in metadata intensive operations. Bye, Alexander. -- Loose bits sink chips. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ttys patch - any objections?
Hi The attached patch gets done by me any time I set up a FreeBSD box (I like lots of VTYs and X on ALT-F12). Any objections to my committing this? M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn Index: etc.alpha/ttys === RCS file: /home/ncvs/src/etc/etc.alpha/ttys,v retrieving revision 1.10 diff -u -d -r1.10 ttys --- etc.alpha/ttys 17 Apr 2002 10:42:39 - 1.10 +++ etc.alpha/ttys 10 Aug 2002 08:26:39 - -41,7 +41,10 ttyv5 /usr/libexec/getty Pc cons25 on secure ttyv6 /usr/libexec/getty Pc cons25 on secure ttyv7 /usr/libexec/getty Pc cons25 on secure -ttyv8 /usr/X11R6/bin/xdm -nodaemon xterm off secure +ttyv8 /usr/libexec/getty Pc cons25 on secure +ttyv9 /usr/libexec/getty Pc cons25 on secure +ttyva /usr/libexec/getty Pc cons25 on secure +ttyvb /usr/X11R6/bin/xdm -nodaemon xterm off secure # Serial terminals # serial console for AlphaServer 8200 and 8400 (TurboLaser) #zs0 /usr/libexec/getty std.9600 vt100 on secure Index: etc.i386/ttys === RCS file: /home/ncvs/src/etc/etc.i386/ttys,v retrieving revision 1.9 diff -u -d -r1.9 ttys --- etc.i386/ttys 17 Apr 2002 10:42:41 - 1.9 +++ etc.i386/ttys 10 Aug 2002 08:27:04 - -41,7 +41,10 ttyv5 /usr/libexec/getty Pc cons25 on secure ttyv6 /usr/libexec/getty Pc cons25 on secure ttyv7 /usr/libexec/getty Pc cons25 on secure -ttyv8 /usr/X11R6/bin/xdm -nodaemon xterm off secure +ttyv8 /usr/libexec/getty Pc cons25 on secure +ttyv9 /usr/libexec/getty Pc cons25 on secure +ttyva /usr/libexec/getty Pc cons25 on secure +ttyvb /usr/X11R6/bin/xdm -nodaemon xterm off secure # Serial terminals # The 'dialup' keyword identifies dialin lines to login, fingerd etc. ttyd0 /usr/libexec/getty std.9600 dialup off secure Index: etc.ia64/ttys === RCS file: /home/ncvs/src/etc/etc.ia64/ttys,v retrieving revision 1.2 diff -u -d -r1.2 ttys --- etc.ia64/ttys 17 Apr 2002 10:42:41 - 1.2 +++ etc.ia64/ttys 10 Aug 2002 08:27:29 - -41,7 +41,10 ttyv5 /usr/libexec/getty Pc cons25 on secure ttyv6 /usr/libexec/getty Pc cons25 on secure ttyv7 /usr/libexec/getty Pc cons25 on secure -ttyv8 /usr/X11R6/bin/xdm -nodaemon xterm off secure +ttyv8 /usr/libexec/getty Pc cons25 on secure +ttyv9 /usr/libexec/getty Pc cons25 on secure +ttyva /usr/libexec/getty Pc cons25 on secure +ttyvb /usr/X11R6/bin/xdm -nodaemon xterm off secure # Serial terminals # The 'dialup' keyword identifies dialin lines to login, fingerd etc. ttyd0 /usr/libexec/getty std.9600 vt100 on secure Index: etc.sparc64/ttys === RCS file: /home/ncvs/src/etc/etc.sparc64/ttys,v retrieving revision 1.3 diff -u -d -r1.3 ttys --- etc.sparc64/ttys4 Aug 2002 19:16:13 - 1.3 +++ etc.sparc64/ttys10 Aug 2002 08:28:00 - -43,7 +43,10 #ttyv5 /usr/libexec/getty Pc cons25 on secure #ttyv6 /usr/libexec/getty Pc cons25 on secure #ttyv7 /usr/libexec/getty Pc cons25 on secure -#ttyv8 /usr/X11R6/bin/xdm -nodaemon xterm off secure +#ttyv8 /usr/libexec/getty Pc cons25 on secure +#ttyv9 /usr/libexec/getty Pc cons25 on secure +#ttyva /usr/libexec/getty Pc cons25 on secure +#ttyvb /usr/X11R6/bin/xdm -nodaemon xterm off secure # Serial terminals # The 'dialup' keyword identifies dialin lines to login, fingerd etc. ttya /usr/libexec/getty local.9600 dialup off secure
Re: Who broke sort(1) ?
It's not like people didn't have nine years' advance warning to fix
their scripts.
When's the first time the FreeBSD sort(1) man page mentioned that this
syntax was deprecated? Can we at least start from there?
The man page in 4.x notes that -k is an alternative rather than the
recommended syntax. Moving something from being officially recommended
syntax in 4.x to dropping the syntax completely in 5.x is verging on
gratuitous breakage, and is going to confuse and piss off a lot of
users. In fact, why does somebody not modify the man page for -stable
to note that it is now deprecated usage, and please use -k instead?
Should this change even make it into 4.7? After all, the sooner the
better, and if 5.0 is going to be released in 6 weeks, that's not much
warning.
I'm all for the making the change in a controlled manner, but let's not
lose sight of the fact that FreeBSD is supposedly a functional operating
system, not a dysfunctional one. Tim Kientzle's suggestion is a good
compromise, and although it may cause some peculiar behaviour in
edge-case situations, it would be a lot better than the dropping the
syntax without warning from one major version to the next.
Nick
(off to fix some _POSIXLY_VERBOTEN scripts, grumble)
--- sort.1.orig Mon Sep 10 12:10:30 2001
+++ sort.1 Thu Sep 26 10:32:04 2002
-5,7 +5,7
.SH SYNOPSIS
.B sort
[\-cmus] [\-t separator] [\-o output-file] [\-T tempdir] [\-bdfiMnr]
-[+POS1 [\-POS2]] [\-k POS1[,POS2]] [file...]
+[\-k POS1[,POS2]] [file...]
.br
.B sort
{\-\-help,\-\-version}
-150,15 +150,19
.I \-c
option, check that no pair of consecutive lines compares equal.
.TP
-.I +POS1 [\-POS2]
+.I \-k POS1[,POS2]
+An alternate syntax for specifying sorting keys.
Specify a field within each line to use as a sorting key. The field
consists of the portion of the line starting at POS1 and up to (but
not including) POS2 (or to the end of the line if POS2 is not given).
-The fields and character positions are numbered starting with 0.
+The fields and character positions are numbered starting with 1.
.TP
-.I \-k POS1[,POS2]
+.I +POS1 [\-POS2]
An alternate syntax for specifying sorting keys.
-The fields and character positions are numbered starting with 1.
+The fields and character positions are numbered starting with 0.
+This syntax is now officially deprecated because it conflicts with
+the POSIX 1003.2 standard. The syntax will be dropped in a future
+release of FreeBSD.
.PP
A position has the form \fIf\fP.\fIc\fP, where \fIf\fP is the number
of the field to use and \fIc\fP is the number of the first character
Re: ttys patch - any objections?
Are old-style non-F11, F12 keyboards still working with FreeBSD? -- Marcin Cieslak // [EMAIL PROTECTED] msg43424/pgp0.pgp Description: PGP signature
Re: ttys patch - any objections?
Are old-style non-F11, F12 keyboards still working with=20 FreeBSD? I don't know, but as those are in the vast minority, its perhaps OK to ask those folks to edit ttys to something more useful to them, rather than the other way round. :-) M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Thu Sep 26 03:14:24 PDT 2002 -- Kernel build for GENERIC completed on Thu Sep 26 03:40:41 PDT 2002 -- Kernel build for LINT started on Thu Sep 26 03:40:42 PDT 2002 -- === vinum cc1: warnings being treated as errors /h/des/src/sys/dev/aac/aac.c: In function `aac_start': /h/des/src/sys/dev/aac/aac.c:726: warning: cast from pointer to integer of different size /h/des/src/sys/dev/aac/aac.c:730: warning: cast from pointer to integer of different size /h/des/src/sys/dev/aac/aac.c: In function `aac_host_response': /h/des/src/sys/dev/aac/aac.c:828: warning: cast to pointer from integer of different size /h/des/src/sys/dev/aac/aac.c: In function `aac_release_command': /h/des/src/sys/dev/aac/aac.c:1083: warning: cast from pointer to integer of different size /h/des/src/sys/dev/aac/aac.c: In function `aac_init': /h/des/src/sys/dev/aac/aac.c:1396: warning: cast from pointer to integer of different size /h/des/src/sys/dev/aac/aac.c:1399: warning: cast from pointer to integer of different size /h/des/src/sys/dev/aac/aac.c:1400: warning: cast from pointer to integer of different size /h/des/src/sys/dev/aac/aac.c: In function `aac_sync_fib': /h/des/src/sys/dev/aac/aac.c:1569: warning: cast from pointer to integer of different size /h/des/src/sys/dev/aac/aac.c: In function `aac_dequeue_fib': /h/des/src/sys/dev/aac/aac.c:1705: warning: cast to pointer from integer of different size /h/des/src/sys/dev/aac/aac.c: In function `aac_ioctl': /h/des/src/sys/dev/aac/aac.c:2213: warning: cast from pointer to integer of different size /h/des/src/sys/dev/aac/aac.c: In function `aac_ioctl_sendfib': /h/des/src/sys/dev/aac/aac.c:2310: warning: int format, different type arg (arg 4) /h/des/src/sys/dev/aac/aac.c:2332: warning: int format, different type arg (arg 4) /h/des/src/sys/dev/aac/aac.c: In function `aac_getnext_aif': /h/des/src/sys/dev/aac/aac.c:2549: warning: cast from pointer to integer of different size *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: troubles with recent -current
On Wed, 25 Sep 2002, Mikhail Teterin wrote: : Attempts to shutdown gracefully result in panic -- negative refcount in vnrele (vfrele?) in vnclose() called from vnclosefile() -- can not be more precise without the serial console and another machine. Same here. cvsup'd this afternoon. sc (or tty*?) appears to be broken -- every once in a while a particular virtual terminal gets locked out. If root was logged in on it, the syslog messages still appear, but there is no cursor and no input. The sure way to replicate is to try to login somewhere with ssh. After the password prompt, the tty is disabled. I can replicate this at will... simply doing a man or more will freeze that virtual terminal. Darren Henderson [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ttys patch - any objections?
On Thu, Sep 26, 2002 at 10:22:15AM +0100, Mark Murray wrote: Hi The attached patch gets done by me any time I set up a FreeBSD box (I like lots of VTYs and X on ALT-F12). Any objections to my committing this? Greedy VTY monster (cf. etc.i386/ttys,v 1.4). :-) Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg43428/pgp0.pgp Description: PGP signature
Re: VFS panic is now fixed.
The VFS panic that was introduced in my recent commits has been fixed. I accidentally commited extra stuff from my tree that was not entirely correct. i just cvs'ed. i'm getting: panic: vn_finished_write: neg cnt danny To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
R e: VFS panic is now fixed.
if this is of any help: panic: vn_finished_write: neg cnt Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db trace Debugger(c04b2d1c,c05664e0,c04bcd6b,cb4607d8,1) at Debugger+0x54 panic(c04bcd6b,cb46082c,c0325417,c05298e0,0) at panic+0xab vn_finished_write(c05298e0,0,c04bc4e0,3ad,c03deb2b) at vn_finished_write+0x22 getnewvnode(c04ce4c9,c240fe00,c1fbc500,cb460884,c67a10ae) at getnewvnode+0x2b7 ffs_vget(c240fe00,831a,2,cb4608f4,8180) at ffs_vget+0x93 ffs_valloc(c25c2940,8180,c241af00,cb4608f4,cb4608f8) at ffs_valloc+0x100 ufs_makeinode(8180,c25c2940,cb460bec,cb460c00,602) at ufs_makeinode+0x69 ufs_create(cb460a48,cb460a68,c0333249,cb460a48,c04e3e60) at ufs_create+0x39 ufs_vnoperate(cb460a48,c04e3e60,c25c2940,cb460bec,cb460c00) at ufs_vnoperate+0x18 VOP_CREATE(c25c2940,cb460bec,cb460c00,cb460aac,2) at VOP_CREATE+0x39 vn_open_cred(cb460bd8,cb460cd8,180,c241af00,cb460cc4) at vn_open_cred+0x179 vn_open(cb460bd8,cb460cd8,180,28f,0) at vn_open+0x29 kern_open(c1f5d240,80b32e0,0,602,1b6) at kern_open+0x183 open(c1f5d240,cb460d10,c04dab80,418,3) at open+0x30 syscall(2f,2f,2f,80b32e0,0) at syscall+0x2be Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (5, FreeBSD ELF32, open), eip = 0x8054953, esp = 0xbfbff75c, ebp = 0xbfbff7a8 --- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ttys patch - any objections?
If you do make this change, make sure it's carefully documented in the release notes. Otherwise we're going to get a lot of surprised I can no longer get back to my X server after I switch away from it's. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Thu, 26 Sep 2002, Mark Murray wrote: Hi The attached patch gets done by me any time I set up a FreeBSD box (I like lots of VTYs and X on ALT-F12). Any objections to my committing this? M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
X crashes gone?
For the last week or so all I had to do to crash the X server was to reboot the machine and fire up X with gnome. The first attempt after a reboot always produced the 'Big Bezier' crash for me. Starting with last night's cvsup I've not seen any more of those crashes. Anyone else notice a difference today? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ttys patch - any objections?
This seems a lot like personal preferance to me, I for one don't like a lot of tty's, because running getty on a bunch of ttys that I'm not going to use is a waste of ram I usually keep F1-F3 as ttys, and make F4 run kdm. I know I don't really have a say, but I'm sure everyone has his or her own preference. Ken On Thu, 26 Sep 2002, Mark Murray wrote: Hi The attached patch gets done by me any time I set up a FreeBSD box (I like lots of VTYs and X on ALT-F12). Any objections to my committing this? M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ttys patch - any objections?
This seems a lot like personal preferance to me, I for one don't like a lot of tty's, because running getty on a bunch of ttys that I'm not going to use is a waste of ram I usually keep F1-F3 as ttys, and make F4 run kdm. I know I don't really have a say, but I'm sure everyone has his or her own preference. Sure! That is why I'm doing a straw poll. If more people seem to like this, I'll commit it. If I get shouted down, I'll keep it as a local hack. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ttys patch - any objections?
culverk This seems a lot like personal preferance to me, I for one culverk don't like a lot of tty's, because running getty on a bunch culverk of ttys that I'm not going to use is a waste of ram Seconded. Two ttys are enough for me. Many getty(8) processes usually waste our process table entry :-) Usually small PC keyboards don't have their own F11/F12 key; key combination such as Fn+F1/Fn+F2 is required (read: a little bit hard to push). It would be better to avoid for the default configuration IMHO. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ttys patch - any objections?
On Thu, Sep 26, 2002 at 02:50:20PM +0100, Mark Murray wrote: This seems a lot like personal preferance to me, I for one don't like a lot of tty's, because running getty on a bunch of ttys that I'm not going to use is a waste of ram I usually keep F1-F3 as ttys, and make F4 run kdm. I know I don't really have a say, but I'm sure everyone has his or her own preference. Sure! That is why I'm doing a straw poll. If more people seem to like this, I'll commit it. If I get shouted down, I'll keep it as a local hack. I agree with Ken that this is a personal preference thingie. I have X tied to F8. There is no real reason for this choice other than inertia. I suspect people who use mergemaster won't have a problem with your proposed change; either they'll accept your change during the merge or keep their current setting. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ttys patch - any objections?
The attached patch gets done by me any time I set up a FreeBSD box (I like lots of VTYs and X on ALT-F12). Any objections to my committing this? I do the opposite, and turn off five vty's to get just three [job control works for me]. -- IMHO a personal like/dislike shouldn't be a reason to introduce changes that affect everyday users' experience. Just my $0.02. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ttys patch - any objections?
Mark Murray writes: Hi The attached patch gets done by me any time I set up a FreeBSD box (I like lots of VTYs and X on ALT-F12). Any objections to my committing this? I object. Most of my machines are headless without video cards and use a serial console. With devfs this means that /dev/ttyv[1-N] do not exist and getty bitches like this: Sep 26 11:00:11 monet getty[543]: open /dev/ttyv1: No such file or directory Its an incredible pain in the ass to get spammed by these things on a 9600 baud serial console while you're editing ttys to turn the damned things off. I don't want to have to have 4 more lines of spam to deal with when installing a new server. If you also fix getty to silently ignore the problem and go to sleep forever, then I withdraw my objection. Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ttys patch - any objections?
In message [EMAIL PROTECTED], Andrew Gallatin w rites: Mark Murray writes: Hi The attached patch gets done by me any time I set up a FreeBSD box (I like lots of VTYs and X on ALT-F12). Any objections to my committing this? I object. Most of my machines are headless without video cards and use a serial console. With devfs this means that /dev/ttyv[1-N] do not exist and getty bitches like this: Sep 26 11:00:11 monet getty[543]: open /dev/ttyv1: No such file or directory Its an incredible pain in the ass to get spammed by these things on a 9600 baud serial console while you're editing ttys to turn the damned things off. I don't want to have to have 4 more lines of spam to deal with when installing a new server. If you also fix getty to silently ignore the problem and go to sleep forever, then I withdraw my objection. I think the right thing to do is to make getty check for DEVFS, an if found just got to sleep. The correct way to check for devfs is to try to read the sysctl variable vfs.devfs.generation, if that succeeds, DEVFS is there and the above failure is non-fatal. It can be argued that it is never fatal though. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: ttys patch - any objections?
On 26-Sep-2002 Mark Murray wrote: Hi The attached patch gets done by me any time I set up a FreeBSD box (I like lots of VTYs and X on ALT-F12). Any objections to my committing this? Yep. I think it's best just to leave things as they are. I pretty much have Alt-F9 hardcoded into my fingers for X. Also, for boxen with serial consoles there's no point in wasting even more space out of the box on extra vty's. Have you tried screen(1) btw? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ttys patch - any objections?
On 26-Sep-2002 Mark Murray wrote: Are old-style non-F11, F12 keyboards still working with=20 FreeBSD? I don't know, but as those are in the vast minority, its perhaps OK to ask those folks to edit ttys to something more useful to them, rather than the other way round. :-) If you add up all the FreeBSD machines in colo's that use serial consoles I think you will find that _you_ are in the vast minority. Plesae leave the ttys file as it is. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ttys patch - any objections?
On 26-Sep-2002 Steve Kargl wrote: On Thu, Sep 26, 2002 at 02:50:20PM +0100, Mark Murray wrote: This seems a lot like personal preferance to me, I for one don't like a lot of tty's, because running getty on a bunch of ttys that I'm not going to use is a waste of ram I usually keep F1-F3 as ttys, and make F4 run kdm. I know I don't really have a say, but I'm sure everyone has his or her own preference. Sure! That is why I'm doing a straw poll. If more people seem to like this, I'll commit it. If I get shouted down, I'll keep it as a local hack. I agree with Ken that this is a personal preference thingie. I have X tied to F8. There is no real reason for this choice other than inertia. I suspect people who use mergemaster won't have a problem with your proposed change; either they'll accept your change during the merge or keep their current setting. New installs on machines don't get to choose this change or not. They just install a machine and now Alt-F9 doesn't get to X anymore. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ttys patch - any objections?
Mark Murray writes: Hi The attached patch gets done by me any time I set up a FreeBSD box (I like lots of VTYs and X on ALT-F12). Any objections to my committing this? I object. Most of my machines are headless without video cards and use a serial console. With devfs this means that /dev/ttyv[1-N] do not exist and getty bitches like this: Sep 26 11:00:11 monet getty[543]: open /dev/ttyv1: No such file or directory Its an incredible pain in the ass to get spammed by these things on a 9600 baud serial console while you're editing ttys to turn the damned things off. I don't want to have to have 4 more lines of spam to deal with when installing a new server. i have the same behavior, to fix this, i've built a post install script to automate some taks (suchs as sendmail configs, directory modes, standard users, cvsup/make world (-STABLE) and more..) Here's a part of this script: # commenting virtual consols in /etc/ttys cp /etc/ttys /tmp/temp_ttys cat /tmp/temp_ttys | sed 's/ttyv[12345678]/#/' /etc/ttys it's a bit porky, but it works... If you also fix getty to silently ignore the problem and go to sleep forever, then I withdraw my objection. my best solution would be a standard postinstall script that you could store on an accessible host, the, after each install, you download and execute that file.. Thus, you wouldn't need to edit the /etc/ttys :) my 2 cents.. fifi... Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Guezou Philippe [EMAIL PROTECTED] FreeBSD, The power to serve.[EMAIL PROTECTED] Buying an operating system without source is like buying a self-assembly Space Shuttle with no instructions. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ttys patch - any objections?
On Thu, Sep 26, 2002 at 11:08:41AM -0400, John Baldwin wrote: On 26-Sep-2002 Steve Kargl wrote: I agree with Ken that this is a personal preference thingie. I have X tied to F8. There is no real reason for this choice other than inertia. I suspect people who use mergemaster won't have a problem with your proposed change; either they'll accept your change during the merge or keep their current setting. New installs on machines don't get to choose this change or not. They just install a machine and now Alt-F9 doesn't get to X anymore. Yes, you're right. I forgot about new installs and the POLA problem. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ttys patch - any objections?
On 26-Sep-2002 Andrew Gallatin wrote:
Mark Murray writes:
Hi
The attached patch gets done by me any time I set up a FreeBSD
box (I like lots of VTYs and X on ALT-F12).
Any objections to my committing this?
I object.
Most of my machines are headless without video cards and use a serial
console. With devfs this means that /dev/ttyv[1-N] do not exist and
getty bitches like this:
Sep 26 11:00:11 monet getty[543]: open /dev/ttyv1: No such file or directory
Its an incredible pain in the ass to get spammed by these things on a
9600 baud serial console while you're editing ttys to turn the damned
things off. I don't want to have to have 4 more lines of spam to
deal with when installing a new server.
If you also fix getty to silently ignore the problem and go to sleep
forever, then I withdraw my objection.
Index: init.c
===
RCS file: /usr/cvs/src/sbin/init/init.c,v
retrieving revision 1.51
diff -u -r1.51 init.c
--- init.c 3 Aug 2002 16:21:33 - 1.51
+++ init.c 26 Sep 2002 15:56:57 -
@@ -939,7 +939,7 @@
* then don't add the device to the session list.
*/
if ((fd = open(sp-se_device, O_RDONLY | O_NONBLOCK, 0)) 0) {
- if (errno == ENXIO) {
+ if (errno == ENXIO || errno == ENOENT) {
free_session(sp);
return (0);
}
(Maybe we should detect devfs somewhere else and use
|| devfs_present errno == ENOENT) instead.)
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Journaled filesystem in CURRENT
On Thu, Sep 26, 2002, Alexander Leidinger wrote: On Wed, 25 Sep 2002 11:12:34 -0700 Brooks Davis [EMAIL PROTECTED] wrote: Does CURRENT support journaled filesystem ? There are not journaling file systems in current at this time. Efforts to port both xfs and jfs are underway. We have something better than those. SoftUpdates. Much faster than jfs in metadata intensive operations. But much slower in some other applications. When we tested several filesystems for mailservers (to store the mail queue), JFS and ext3 (in journal mode) beat UFS with softupdates by about a factor of 2. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Journaled filesystem in CURRENT
On Thu, 26 Sep 2002 10:52:18 -0500 Dan Nelson [EMAIL PROTECTED] wrote: We have something better than those. SoftUpdates. Much faster than jfs in metadata intensive operations. If you can stand the 20 minutes of severly degraded performance while the background fsck runs after a crash, and the loss of any files Sometimes it's better to have 20 minutes (or how long it takes to do the bg-fsck on your FS) degraded performance, than no performance at all (you can have this too, just configure the system to make an fg-fsck instead of a bg-fsck)... (how long does it take to check the journal and to do some appropriate actions depending on the journal?) created up to 30 seconds (by default) before the crash. There's no guarantee with a journaled fs, that the data before the crash is on the disk. A journaled fs is in the same boat with SO here. Bye, Alexander. -- Secret hacker rule #11: hackers read manuals. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ttys patch - any objections?
In article [EMAIL PROTECTED] Mark Murray [EMAIL PROTECTED] writes: The attached patch gets done by me any time I set up a FreeBSD box (I like lots of VTYs and X on ALT-F12). Any objections to my committing this? PC-98x1 keyboards have only ten function keys. So, it is impossible to use F11 and F12 keys. --- TAKAHASHI Yoshihiro [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Journaled filesystem in CURRENT
In the last episode (Sep 26), Alexander Leidinger said: On Wed, 25 Sep 2002 11:12:34 -0700 Brooks Davis [EMAIL PROTECTED] wrote: Does CURRENT support journaled filesystem ? There are not journaling file systems in current at this time. Efforts to port both xfs and jfs are underway. We have something better than those. SoftUpdates. Much faster than jfs in metadata intensive operations. If you can stand the 20 minutes of severly degraded performance while the background fsck runs after a crash, and the loss of any files created up to 30 seconds (by default) before the crash. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Journaled filesystem in CURRENT
Claus Assmann wrote: Does CURRENT support journaled filesystem ? There are not journaling file systems in current at this time. Efforts to port both xfs and jfs are underway. We have something better than those. SoftUpdates. Much faster than jfs in metadata intensive operations. But much slower in some other applications. When we tested several filesystems for mailservers (to store the mail queue), JFS and ext3 (in journal mode) beat UFS with softupdates by about a factor of 2. Hi Claus! Nice to hear from someone who actually tests things! I think that what you were probably testing was directory entry layout and O(N) (linear) vs. O(log2(N)+1) search times for both non-existant entries on creates, and for any entry on lookup ( / 2 on lookup) . The best answer for inbound mail is to go to per domain mail queues, and the best for outbound is to go to hashed outbound domains (as we discussed at the 2000 Sendmail MOTM gathering). Per domain mail queues inbound give you a 100% hit rate on a directory traversal for a queue flush; using hashed outbound directories isn't a 100% hit rate, but you can keep it above 85% with the right hashing structure, which makes the miss rate have only 1-2% impact on processing. That said, journalling and Soft Updates are totally orthogonal technologies, just as btree and linear directory structures are two orthogonal things. Journalling has advantages that a non-journalling FS with soft updates does not -- can not -- have, particularly since it is not possible to distinguish a power failure from a hardware failure from (some) software failures, and those cases need to be treated differently for the purposes of recovery. The soft updates background recover can not do this; the foregound recovery can, but only if it's not the abbreviated version. A JFS that journals both data and metadata can recover from all three, to a consistant state, and one that journals only metadata can recover from two of them. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Journaled filesystem in CURRENT
On Thu, Sep 26, 2002 at 10:36:27AM -0700, Terry Lambert wrote: I think that what you were probably testing was directory entry layout and O(N) (linear) vs. O(log2(N)+1) search times for both non-existant entries on creates, and for any entry on lookup ( / 2 on lookup) . Though dirhash should eliminate most of this... David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Journaled filesystem in CURRENT
David Malone wrote: On Thu, Sep 26, 2002 at 10:36:27AM -0700, Terry Lambert wrote: I think that what you were probably testing was directory entry layout and O(N) (linear) vs. O(log2(N)+1) search times for both non-existant entries on creates, and for any entry on lookup ( / 2 on lookup) . Though dirhash should eliminate most of this... Everybody alsways says that, and then backs off, when they realize that a traversal of a mail queue of 100,000 entries, in which the destination is known by the contents of the file, rather than the file name, is involved. 8-). IMO, dirhash is useful in small cases, particularly where locality of reference is important... which means not during linear traversals of 100% of a directory on create/iterate and not during linear traversals of 50% of a directory on lookup of a specific file which exists or 100% of a directory for a specific file that ends up not existing. Cranking the size of the hash up only works to a certain point. Claus would have to answer this, but I'm pretty sure that the machines he tested on would have had dirhash, and still ended up getting bad results for his application (sendmail queue directories). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Journaled filesystem in CURRENT
On Thu, Sep 26, 2002 at 10:36:27AM -0700, Terry Lambert wrote: I think that what you were probably testing was directory entry layout and O(N) (linear) vs. O(log2(N)+1) search times for both non-existant entries on creates, and for any entry on lookup ( / 2 on lookup) . Though dirhash should eliminate most of this... Everybody alsways says that, and then backs off, when they realize that a traversal of a mail queue of 100,000 entries, in which the destination is known by the contents of the file, rather than the file name, is involved. 8-). If you are searching based on contents of a file, then any directory layout scheme will require mean N/2 probes on success and N on failure surely? And if these probes are linear (ie. in the order they are in the directory) then this really is O(N) both with and without dirhash 'cos the probles will be O(1). David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Journaled filesystem in CURRENT
On Thu, Sep 26, 2002, Terry Lambert wrote: Claus Assmann wrote: When we tested several filesystems for mailservers (to store the mail queue), JFS and ext3 (in journal mode) beat UFS with softupdates by about a factor of 2. Hi Claus! Nice to hear from someone who actually tests things! I think that what you were probably testing was directory entry layout and O(N) (linear) vs. O(log2(N)+1) search times for both non-existant entries on creates, and for any entry on lookup ( / 2 on lookup) . I doubt it. The number of files in the queue directories was fairly small during the runs. Moreover, ReiserFS showed fairly poor performance, even though it should be good for directory lookups, right? The best answer for inbound mail is to go to per domain mail queues, and the best for outbound is to go to hashed outbound domains (as we discussed at the 2000 Sendmail MOTM gathering). Per domain mail queues inbound give you a 100% hit rate on a directory traversal for a queue flush; using hashed outbound directories isn't a 100% hit rate, but you can keep it above 85% with the right hashing structure, which makes the miss rate have only 1-2% impact on processing. Per domain doesn't work easily if you have multiple recipients. Anyway, the new design clearly distinguishes between the content files and the data that is necessary for delivery. If someone is interested: http://www.sendmail.org/~ca/email/sm-9-rfh.html Just as a small data point: I get message acceptance rates of 400msgs/s on a journalling file system (using a normal PC) that writes the data into the journal too. AFAICT that's due to the fact that fsync() is much fast for this kind of storage. The important part for mailservers here is the rate at which content files can by safely written to disk. From my limited experience journalling file systems are here much better than softupdates. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Journaled filesystem in CURRENT
On Thu, 26 Sep 2002, Claus Assmann wrote: On Thu, Sep 26, 2002, Terry Lambert wrote: Claus Assmann wrote: When we tested several filesystems for mailservers (to store the mail queue), JFS and ext3 (in journal mode) beat UFS with softupdates by about a factor of 2. Hi Claus! Nice to hear from someone who actually tests things! I think that what you were probably testing was directory entry layout and O(N) (linear) vs. O(log2(N)+1) search times for both non-existant entries on creates, and for any entry on lookup ( / 2 on lookup) . I doubt it. The number of files in the queue directories was fairly small during the runs. Moreover, ReiserFS showed fairly poor performance, even though it should be good for directory lookups, right? The best answer for inbound mail is to go to per domain mail queues, and the best for outbound is to go to hashed outbound domains (as we discussed at the 2000 Sendmail MOTM gathering). Per domain mail queues inbound give you a 100% hit rate on a directory traversal for a queue flush; using hashed outbound directories isn't a 100% hit rate, but you can keep it above 85% with the right hashing structure, which makes the miss rate have only 1-2% impact on processing. Per domain doesn't work easily if you have multiple recipients. Anyway, the new design clearly distinguishes between the content files and the data that is necessary for delivery. If someone is interested: http://www.sendmail.org/~ca/email/sm-9-rfh.html Just as a small data point: I get message acceptance rates of 400msgs/s on a journalling file system (using a normal PC) that writes the data into the journal too. AFAICT that's due to the fact that fsync() is much fast for this kind of storage. The important part for mailservers here is the rate at which content files can by safely written to disk. From my limited experience journalling file systems are here much better than softupdates. Can you tell me the approximate sizes of these mails and how they are stored? -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Journaled filesystem in CURRENT
I've been having loads of problems with the bg-fsck. After recovering from a crash/power failure my machine will boot and start the check. If there's moderate activity during the time its checking it will panic and reboot, getting stuck in a loop most of the time. I've not seen anyone mention this on the list, but I was wondering if anyone's experienced this? This has been ongoing across many cvsups and buildworlds. Thanks, Scott Alexander Leidinger[EMAIL PROTECTED] 09/26/02 12:23PM On Thu, 26 Sep 2002 10:52:18 -0500 Dan Nelson [EMAIL PROTECTED] wrote: We have something better than those. SoftUpdates. Much faster than jfs in metadata intensive operations. If you can stand the 20 minutes of severly degraded performance while the background fsck runs after a crash, and the loss of any files Sometimes it's better to have 20 minutes (or how long it takes to do the bg-fsck on your FS) degraded performance, than no performance at all (you can have this too, just configure the system to make an fg-fsck instead of a bg-fsck)... (how long does it take to check the journal and to do some appropriate actions depending on the journal?) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Journaled filesystem in CURRENT
David Malone wrote: On Thu, Sep 26, 2002 at 10:36:27AM -0700, Terry Lambert wrote: I think that what you were probably testing was directory entry layout and O(N) (linear) vs. O(log2(N)+1) search times for both non-existant entries on creates, and for any entry on lookup ( / 2 on lookup) . Though dirhash should eliminate most of this... Everybody alsways says that, and then backs off, when they realize that a traversal of a mail queue of 100,000 entries, in which the destination is known by the contents of the file, rather than the file name, is involved. 8-). If you are searching based on contents of a file, then any directory layout scheme will require mean N/2 probes on success and N on failure surely? And if these probes are linear (ie. in the order they are in the directory) then this really is O(N) both with and without dirhash 'cos the probles will be O(1). ~O((N^4)/8)/2, actually. You linearly traverse for the queue element files, and then the queue elelement files tell you name of the queue content file, which you you have to look up. So it's a combined traversal and lookup on the same directory (in fact: a dirhash buster, with some of the least optimal behaviour possible). There are two additional lookups, which occur to unlink the queue entry file, and the message file, so it's really (for n queue entries, which means twice that many directory entries): N = n*2 \ O(N) * O(N/2) * O(N/2) * O((N-1)/2) / N = 0 (Assuming successful delivery and removal of the queue files on each element iterated). The way this is fixed in ext3 or most JFS implementations (both XFS and IBM's OS/2 JFS for Linux) is that the linear traversal is linear... meaning you don't restart the scan each time... and the explicit file lookup is O(log2(N+1)). N * log2(N+1)^3 is significantly smaller than (N^4)/8 (in case you were wondering about the /8, it's because statistically, you only have to traverse 50% of the directory entries, on average, for a linear lookup that results in a hit, but that only applies to explicit lookups, not the traversal); the result is (again for n queue entries): N = n*2 \ O(N) * O(log2(N+1)) * O(log2(N+1)) * O(log2(N)) / N = 0 There are other data structures that could reduce this further than btree, FWIW, but implementing them in directories is moderately hard because of metadata ordering guarantees, and directory entry locking. Still, it's probably worth doing, if you can figure out a way to eliminate the need for directory vnode locking for modification operations (or can make them over into range-lock operations, instead). One obvious fix is to time-order file creations, to try and keep block locality close to time locality (i.e., if you are going to create 2 files (f1,f2) in some time interval [t1..t2], then you try to guarantee that the directory entry block that contains f2 is after the cone that contains f1, so that a linear progressive search from the current linear traversal location that resulted in f1 being found is likely to find f2, either immediately, or at least within the next block or two). The problem with doing this is the inability to ensure that the file you are creating does not exist... without a full traversal. This requires that there is some cooperation involved, so that the lookup traversal is picked up following the current offset of the linear traversal in progress. It also fails, if simultaneos traversals occur... assuming that the offset is not maintained per-process, but instead, per directory. If it's per-process, it actually works out, but only because each process in the sendmail case only has one queue run going on at a time. Note that none of this accounts for the queue entry creation of two additional files; that's a O(4*N+1), since create requires that the file not already exist (and is not helped by dirhash at all, being linear, by definition). For a btree, that's only O(2*log2(N+1)+2) for the two insertions. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Journaled filesystem in CURRENT
On Thu, 26 Sep 2002 10:36:27 -0700 Terry Lambert [EMAIL PROTECTED] wrote: That said, journalling and Soft Updates are totally orthogonal technologies, just as btree and linear directory structures are two orthogonal things. Journalling has advantages that a non-journalling FS with soft updates does not -- can not -- have, particularly since it is not possible to distinguish a power failure from a hardware failure from (some) software failures, and those cases need to Power failure: No problem for both. Hardware failure (I assume you think about a HDD failure): Read failure: doesn't matter here Write failure: either the sector gets remapped (no problem for both), or the disk is in self destruct mode (both can't cope with this) Software failure: Are you talking about bugs in the FS code? Or about a nasty person which writes some bad data into the FS structures? be treated differently for the purposes of recovery. The soft Sorry, I don't get it. Can you please be more verbose? updates background recover can not do this; the foregound recovery can, but only if it's not the abbreviated version. A What are you talking about? Did you managed to get an unexpected softupdates inconsistency after the last bugfix? I don't see a difference in the power or hardware failure cases for a journaled fs and SO. The only reason for a fg-fsck instead of a bg-fsck (in the there's no bug in the bg-fsck code path case) is if someone damages the fs-structures on disk (I assume there are no bugs in SO anymore which result in an unexpected SO inconsistency). Note: I don't think the actual code path for bg-fsck is bugfree at the moment (read: I don't trust it at the moment). JFS that journals both data and metadata can recover from all three, to a consistant state, and one that journals only metadata can recover from two of them. SO writes the data directly to free sectors in the target filesystem. I don't see where journaled data is an improvement in fs-consistency here. Bye, Alexander. -- It's not a bug, it's tradition! http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Journaled filesystem in CURRENT
On Thu, 26 Sep 2002 14:54:00 -0400 Scott Dodson [EMAIL PROTECTED] wrote: I've been having loads of problems with the bg-fsck. After recovering from a crash/power failure my machine will boot and start the check. If there's moderate activity during the time its checking it will panic and reboot, getting stuck in a loop most of the time. I've not seen anyone mention this on the list, but I was wondering if anyone's experienced this? This has been ongoing across many cvsups and buildworlds. Yes, bg-fsck isn't really usable at the moment. Bye, Alexander. -- Press every key to continue. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Journaled filesystem in CURRENT
Claus Assmann wrote: [ ... out of order answer, not related to main topic ... ] Per domain doesn't work easily if you have multiple recipients. Anyway, the new design clearly distinguishes between the content files and the data that is necessary for delivery. Actually, it works fine, since it performs queue entry splitting, in the case of multiple recipients. That yields a 100% hit rate for per domain queue traversals, since they contain only messages destined for the domain in question. But back to JFS... [ ... ] I doubt it. The number of files in the queue directories was fairly small during the runs. Moreover, ReiserFS showed fairly poor performance, even though it should be good for directory lookups, right? [ ... ] Just as a small data point: I get message acceptance rates of 400msgs/s on a journalling file system (using a normal PC) that writes the data into the journal too. AFAICT that's due to the fact that fsync() is much fast for this kind of storage. The important part for mailservers here is the rate at which content files can by safely written to disk. From my limited experience journalling file systems are here much better than softupdates. I didn't realize you qere running in safe mode; I should have realized that, since it was supposed to be the only possibility in a future revision, the last time I looked at the particular code in question. I guess I had a stale cache. 8-) 8-). Note that fsync() is a data operation, not a metadata operation, in this case, and what we are talking about is queue contents being committed to stable storage (prior to the 250 Accepted response, presumably). Yes, soft updates does nothing of user data, it is a metadata technology. Journalling is implementation dependent; not all JFS implementations will journal data which is not metadata, so your results would depend on the JFS. Yes, if your data is journalled, too, then what it means is that an fsync() is, effectively, a noop, since the commit to the stable journal entry is (supposedly) guaranteed before the write call returns. That's a *big* supposedly, though. Note that this is potentially not a real commit, though, and you would be better off testing with power disconnects on very large queues. The reason for this is that you need to verify that the drives are not, in fact, lying to you, by enabling write caching, and then returning that the data has been committed, when in fact it has not. The difference you are seeing might be attributable to the drive setting for write caching, in the various OSs (e.g. one with it disabled, the other with it enabled). Journalling does not always mean data integrity (it was only ever intended to mean transactional data integrity, in any case, meaning you can and sometimes do lose transactions in event of a failure). If you want to compare apples and apples, you should verify that the data is in fact journalled, that the fsync() actually does what it's supposed to do, if the data is not, and that the code path all the way to the disk supports real commits to stable storage (#1 thing here is: turn off drive write caching in all cases). Large queue testing would show the effects that I've discussed in other emails. I don't think large throughput with short queue depths is representative of mail servers (unless you are an open relay, of course ;^)). I understand the desire for this, though, if you are comparing a 2-file queue to a 1-file queue, given the other effects on deeper queues. 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Journaled filesystem in CURRENT
Terry Lambert wrote: Yes, soft updates does nothing of user data, it is a metadata technology. Journalling is implementation dependent; not all JFS implementations will journal data which is not metadata, so your results would depend on the JFS. I think you are not correct here. If I understand Kirks paper right, Soft Updates do a sorting/nesting of data and metadata within the buffer cache. My knowledge is, that most of the journaling implementations do metadata journaling and do not guarantee data consistency (ext3 with data=journal is the only exception I know of), whereas SU *does* guarantee data consistency (admittedly with a time lag) because of that nesting from data with metadata. I'm far away from beeing able to follow this discussion in every detail, but please correct me if I'm wrong... -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) Powered by FreeBSD 4.7-RC To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ttys patch - any objections?
On 2002-09-26 14:50, Mark Murray [EMAIL PROTECTED] wrote: This seems a lot like personal preferance to me, I for one don't like a lot of tty's, because running getty on a bunch of ttys that I'm not going to use is a waste of ram I usually keep F1-F3 as ttys, and make F4 run kdm. I know I don't really have a say, but I'm sure everyone has his or her own preference. Sure! That is why I'm doing a straw poll. If more people seem to like this, I'll commit it. If I get shouted down, I'll keep it as a local hack. I customarily turn some of them off. All I need is 2-3 vtys, to run a couple of screen(1) sessions. My own local set of changes includes a patch that is almost the opposite of the proposed change (all vtys are turned off, except for ttyv[0123]---the first four). Giorgos. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
IBM microdrive
Is anyone using IBM microdrive with latest current? Should it work? My laptop is Toshiba CT3440 running current cvsupped last weekend. My Cisco Aironet and Linksys network cards are working just fine with this new card concept. pccard0: Allocation failed for cfe 0 ata2 at port 0x100-0x10f irq 11 function 0 config 1 on pccard0 pccard0: WARNING: Resource not reserved by pccard bus device_probe_and_attach: ata2 attach returned 6 Tomppa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
NIC not found
I am doing an ftp install for -current. I pulled the kern.flp and mfsroot.flp from 5.0-CURRENT-20020917-JPSNAP. When I went to select the media, I found the my Intel NIC was not found. 4.7-RC found the card: fxp0: Intel Pro/100 Ethernet port 0xe000-0xe03f mem 0xeb00-0xeb0f,0xeb10-0xeb100fff irq 10 at device 11.0 on pci0 fxp0: Ethernet address 00:d0:b7:90:c3:ac but -current doesnt see it. There were some items that were probed but could not be assigned resources: PNP0303 PNP0501 PNP0700 PNP0400 PNP0501 Is there any work around? -- /\ | Bob Bomar [EMAIL PROTECTED] http://www.bomar.us/~bob | || | FreeBSD: The Power to Serve. http://www.freeBSD.org | \/ msg43464/pgp0.pgp Description: PGP signature
Re: ttys patch - any objections?
At 10:22 AM +0100 9/26/02, Mark Murray wrote: Hi The attached patch gets done by me any time I set up a FreeBSD box (I like lots of VTYs and X on ALT-F12). Any objections to my committing this? I think the we will have more users who are hurt (or at least annoyed) by moving X, then we have users who need more tty's in freebsd out-of-the-box. I wouldn't quite say that I object to the change, but I see no point in doing it. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Thu Sep 26 15:20:27 PDT 2002 -- Kernel build for GENERIC completed on Thu Sep 26 15:50:41 PDT 2002 -- Kernel build for LINT started on Thu Sep 26 15:50:41 PDT 2002 -- === vinum cc1: warnings being treated as errors /h/des/src/sys/dev/advansys/adv_pci.c: In function `adv_pci_attach': /h/des/src/sys/dev/advansys/adv_pci.c:197: warning: overflow in implicit constant conversion *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Thu, 26 Sep 2002, Dag-Erling Smorgrav wrote:
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
--
stage 2: rebuilding the object tree
--
stage 2: build tools
--
stage 3: cross tools
--
stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include
--
stage 4: building libraries
--
stage 4: make dependencies
--
stage 4: building everything..
--
Kernel build for GENERIC started on Thu Sep 26 15:20:27 PDT 2002
--
Kernel build for GENERIC completed on Thu Sep 26 15:50:41 PDT 2002
--
Kernel build for LINT started on Thu Sep 26 15:50:41 PDT 2002
--
=== vinum
cc1: warnings being treated as errors
/h/des/src/sys/dev/advansys/adv_pci.c: In function `adv_pci_attach':
/h/des/src/sys/dev/advansys/adv_pci.c:197: warning: overflow in implicit constant
conversion
*** Error code 1
Stop in /h/des/obj/h/des/src/sys/LINT.
*** Error code 1
Stop in /h/des/src.
*** Error code 1
Stop in /h/des/src.
I don't understand why this error occurs since the types all seem to
match.
Relevant lines from src/sys/dev/advansys/adv_pci.c:
/* Allocate a dmatag for our transfer DMA maps */
/* XXX Should be a child of the PCI bus dma tag */
error = bus_dma_tag_create(/*parent*/NULL, /*alignment*/1,
/*boundary*/0,
/*lowaddr*/ADV_PCI_MAX_DMA_ADDR,
/*highaddr*/BUS_SPACE_MAXADDR,
/*filter*/NULL, /*filterarg*/NULL,
/*maxsize*/BUS_SPACE_MAXSIZE_32BIT,
/*nsegments*/BUS_SPACE_UNRESTRICTED,
/*maxsegsz*/ADV_PCI_MAX_DMA_COUNT,
/*flags*/0,
197 - adv-parent_dmat);
Yet in src/sys/alpha/include/bus.h:
typedef struct bus_dma_tag *bus_dma_tag_t;
...
int bus_dma_tag_create(bus_dma_tag_t parent, bus_size_t alignemnt,
bus_size_t boundary, bus_addr_t lowaddr,
bus_addr_t highaddr, bus_dma_filter_t *filtfunc,
void *filtfuncarg, bus_size_t maxsize, int
nsegments,
bus_size_t maxsegsz, int flags, bus_dma_tag_t
*dmat);
And advlib.h:
struct adv_softc {
...
bus_dma_tag_tparent_dmat;
}
Everything seems to line up, why the warning?
-Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
Nate Lawson wrote: On Thu, 26 Sep 2002, Dag-Erling Smorgrav wrote: -- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/i nclude -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Thu Sep 26 15:20:27 PDT 2002 -- Kernel build for GENERIC completed on Thu Sep 26 15:50:41 PDT 2002 -- Kernel build for LINT started on Thu Sep 26 15:50:41 PDT 2002 -- === vinum cc1: warnings being treated as errors /h/des/src/sys/dev/advansys/adv_pci.c: In function `adv_pci_attach': /h/des/src/sys/dev/advansys/adv_pci.c:197: warning: overflow in implicit co nstant conversion *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. I don't understand why this error occurs since the types all seem to match. Relevant lines from src/sys/dev/advansys/adv_pci.c: /* Allocate a dmatag for our transfer DMA maps */ /* XXX Should be a child of the PCI bus dma tag */ error = bus_dma_tag_create(/*parent*/NULL, /*alignment*/1, /*boundary*/0, /*lowaddr*/ADV_PCI_MAX_DMA_ADDR, /*highaddr*/BUS_SPACE_MAXADDR, /*filter*/NULL, /*filterarg*/NULL, /*maxsize*/BUS_SPACE_MAXSIZE_32BIT, /*nsegments*/BUS_SPACE_UNRESTRICTED, /*maxsegsz*/ADV_PCI_MAX_DMA_COUNT, /*flags*/0, 197 - adv-parent_dmat); Yet in src/sys/alpha/include/bus.h: typedef struct bus_dma_tag *bus_dma_tag_t; ... int bus_dma_tag_create(bus_dma_tag_t parent, bus_size_t alignemnt, bus_size_t boundary, bus_addr_t lowaddr, bus_addr_t highaddr, bus_dma_filter_t *filtfunc, void *filtfuncarg, bus_size_t maxsize, int nsegments, bus_size_t maxsegsz, int flags, bus_dma_tag_t *dmat); gcc is telling you the wrong line. The problem is here: int nsegments; vs: /*nsegments*/BUS_SPACE_UNRESTRICTED, note that: bus.h:#define BUS_SPACE_UNRESTRICTED(~0UL) 0x will not fit in an int. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
make buildworld
hi all i get the follow error mesgs when i make builword after cvsup my current ,and i found the sendmail as the same. btxld -v -E 0x1000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin btxld: Cannot allocate memory *** Error code 2 Stop in /usr/src/sys/boot/i386/boot2. thanks any info To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
$60,000,000 IN 6 MONTHS! VERIFIABLE! CHEAT-PROOF!
MY PERSONAL GOAL IS TO MAKE CERTAIN THAT YOU RECEIVE $60,000,000 IN 6 MONTHS OR LESS! FACT #1 Those who get in on a proven successful program at it's birth are guaranteed success! FACT #2 THE UP WAS JUST BORN! YOU ARE AT YOUR DREAM LOCATION! THIS IT IT! * JUST LAUNCHED! *YOU CANNOT LOSE! *WE WON'T LET YOU! *OUR GOAL IS TO GET YOU $60,000,000 IN 6 MONTHS OR LESS! *JOIN A FRATERNITY OF HELPERS WHO WILL HELP YOU SUCCEED! *THE ULITMATE PROGRAM (UP) IS THE BEST PROGRAM IN EXISTENCE! *THE LAST PROGRAM YOU WILL EVER JOIN! STOP playing around with programs that possibly get you $20,000 or $40,000. We will help YOU get $60,000,000 IN 6 MONTHS OR LESS! The UP out-performs any other program because it's self-regulated. 100% Cheatproof and Verifiable. YOU VERIFY EACH MEMBER IS REAL BEFORE YOU JOIN! Thereby eliminating ALL guesswork! SIMPLE TO DO + YOU ARE NEVER ALONE! FRATERNITY OF HELPERS helping EACH OTHER SUCCEED! Your success is Our Success! Get your FREE copy ot THE UP! Request THE UP by email, with 'SEND UP in the Subject LIne to: [EMAIL PROTECTED] OR Go to the Official UP Site for more information at: http://www.theultimateprogram.com/default.asp?up=2054 My goal is for you to receive: $60,000,000 IN 6 MONTHS OR LESS! WE CAN DO THIS! When YOU SUCCEED, I SUCCEED, AND WE ALL WIN! JOIN THE UP TODAY before the Members List fills up! Sincerely, Nancy Harlan UP Member [EMAIL PROTECTED] GO TO THE OFFICIAL SITE: http://www.theultimateprogram.com/default.asp?up=2054 ANY QUESTIONS, ANYTIME! [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: R e: VFS panic is now fixed.
On Thu, 26 Sep 2002, Danny Braniss wrote: if this is of any help: panic: vn_finished_write: neg cnt Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db trace Debugger(c04b2d1c,c05664e0,c04bcd6b,cb4607d8,1) at Debugger+0x54 panic(c04bcd6b,cb46082c,c0325417,c05298e0,0) at panic+0xab vn_finished_write(c05298e0,0,c04bc4e0,3ad,c03deb2b) at vn_finished_write+0x22 getnewvnode(c04ce4c9,c240fe00,c1fbc500,cb460884,c67a10ae) at getnewvnode+0x2b7 ffs_vget(c240fe00,831a,2,cb4608f4,8180) at ffs_vget+0x93 ffs_valloc(c25c2940,8180,c241af00,cb4608f4,cb4608f8) at ffs_valloc+0x100 ufs_makeinode(8180,c25c2940,cb460bec,cb460c00,602) at ufs_makeinode+0x69 ufs_create(cb460a48,cb460a68,c0333249,cb460a48,c04e3e60) at ufs_create+0x39 ufs_vnoperate(cb460a48,c04e3e60,c25c2940,cb460bec,cb460c00) at ufs_vnoperate+0x18 VOP_CREATE(c25c2940,cb460bec,cb460c00,cb460aac,2) at VOP_CREATE+0x39 vn_open_cred(cb460bd8,cb460cd8,180,c241af00,cb460cc4) at vn_open_cred+0x179 vn_open(cb460bd8,cb460cd8,180,28f,0) at vn_open+0x29 kern_open(c1f5d240,80b32e0,0,602,1b6) at kern_open+0x183 open(c1f5d240,cb460d10,c04dab80,418,3) at open+0x30 syscall(2f,2f,2f,80b32e0,0) at syscall+0x2be Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (5, FreeBSD ELF32, open), eip = 0x8054953, esp = 0xbfbff75c, ebp = 0xbfbff7a8 --- I am not able to reproduce this. Can you tell me how your kernel conf differs from GENERIC as well as provide some details on how you trigered this? Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make buildworld
I had this problem on my box when libc and the kernel got out of sync. I solved it with: cd /usr/src/libc; make all install -Nate On Fri, 27 Sep 2002, wsk wrote: hi all i get the follow error mesgs when i make builword after cvsup my current ,and i found the sendmail as the same. btxld -v -E 0x1000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin btxld: Cannot allocate memory *** Error code 2 Stop in /usr/src/sys/boot/i386/boot2. thanks any info To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Journaled filesystem in CURRENT
On Thu, Sep 26, 2002 at 09:13:41PM +0200, Alexander Leidinger wrote: Yes, bg-fsck isn't really usable at the moment. They work fine for me for quite a while. The last buildworld on my server was Sept 15th. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Journaled filesystem in CURRENT
On Thu, Sep 26, 2002, Zhihui Zhang wrote: On Thu, 26 Sep 2002, Claus Assmann wrote: If someone is interested: http://www.sendmail.org/~ca/email/sm-9-rfh.html Just as a small data point: I get message acceptance rates of 400msgs/s on a journalling file system (using a normal PC) that writes the data into the journal too. AFAICT that's due to the fact that fsync() is much fast for this kind of storage. The important part for mailservers here is the rate at which content files can by safely written to disk. From my limited experience journalling file systems are here much better than softupdates. Can you tell me the approximate sizes of these mails and how they are stored? The test for sendmail 9 were made with small sizes (1-4KB). They were stored in flat files using 16 directories. The performance tests for sendmail 8 were done with sizes from 1 to 40 KB, in a single queue directory (AFAIR). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Thu, 26 Sep 2002, Peter Wemm wrote: Nate Lawson wrote: On Thu, 26 Sep 2002, Dag-Erling Smorgrav wrote: Kernel build for LINT started on Thu Sep 26 15:50:41 PDT 2002 -- === vinum cc1: warnings being treated as errors /h/des/src/sys/dev/advansys/adv_pci.c: In function `adv_pci_attach': /h/des/src/sys/dev/advansys/adv_pci.c:197: warning: overflow in implicit co nstant conversion *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. I don't understand why this error occurs since the types all seem to match. Relevant lines from src/sys/dev/advansys/adv_pci.c: /* Allocate a dmatag for our transfer DMA maps */ /* XXX Should be a child of the PCI bus dma tag */ error = bus_dma_tag_create(/*parent*/NULL, /*alignment*/1, /*boundary*/0, /*lowaddr*/ADV_PCI_MAX_DMA_ADDR, /*highaddr*/BUS_SPACE_MAXADDR, /*filter*/NULL, /*filterarg*/NULL, /*maxsize*/BUS_SPACE_MAXSIZE_32BIT, /*nsegments*/BUS_SPACE_UNRESTRICTED, /*maxsegsz*/ADV_PCI_MAX_DMA_COUNT, /*flags*/0, 197 - adv-parent_dmat); gcc is telling you the wrong line. The problem is here: int nsegments; vs: /*nsegments*/BUS_SPACE_UNRESTRICTED, note that: bus.h:#define BUS_SPACE_UNRESTRICTED(~0UL) 0x will not fit in an int. I looked at this some more. Would it be ok to make it (~0) since we'll never need 64 bits worth of nsegments? -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
moused problem
While trying to debug a small mouse misbehavior I discovered that the /etc/rc.d/moused script doesn't work correctly. It starts the moused properly but when I type '/etc/rc.d/moused stop' it says 'moused not running?' and leaves moused running. Anyone else see this? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
cant find libc.so.4
Hello freebsd-current, I just downloaded the 5.0 DP1 iso and have some questions. First i noticed the pkg_add ...via ftp is broken as it does not want to use the tbz packages even with the -r flag. Is this a bug being fixed for the new format .tbz or is freebsd going to revert back to the .tgz instead. anyways i installed the system and everythings working great. i did not install kde or gnome as i wanted to just use X with Afterstep. As i mentioned the .tbz pkg_add is broken when using a network resource, local disk seems to work, so i searched on google and saw a thread that said to use the tgz packages from 4.6.2 and they would work fine. ok i pkg_add via ftp the Afterstep-1.8.11 and it did install and installed several other items that i assume were deps. thats why i wanted to use the ftp methode because i thought it found all the deps and installed them for you. ok the problem with afterstep is when i try to start it i am getting the following error: /usr/libexec/ld-elf.so.1: Shared object libc.so.4 not found where can i get this lib and do i just add it to the ldd path? If i wanted to run current how would i find the latest .iso or do we have to make our own for these snapshots? I am comming from openbsd so please be patient as i learn the minnor differences. -- Best regards, SweeTLeaF mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
