From owner-freebsd-hackers Sun Apr 8 10:45: 7 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from chmod.ath.cx (CC2-1242.charter-stl.com [24.217.116.226]) by hub.freebsd.org (Postfix) with ESMTP id 5EDB037B422 for ; Sun, 8 Apr 2001 10:45:05 -0700 (PDT) (envelope-from ajh3@chmod.ath.cx) Received: by chmod.ath.cx (Postfix, from userid 1001) id A9D4CA91E; Sun, 8 Apr 2001 12:44:07 -0500 (CDT) Date: Sun, 8 Apr 2001 12:44:07 -0500 From: Andrew Hesford To: FreeBSD-hackers Subject: burncd code Message-ID: <20010408124407.A61837@cec.wustl.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Loop: Andrew Hesford Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm sure you've all heard about troubles with burncd and audio CDs. I'm one of the people having trouble. I can write data CDs just fine, but when I try to burn an audio disc, it fails, no matter what speed. It simply says "writing -1 of XXXXX bytes" and quits. If I try to fixate the disc in the same pass, it gives me an ioctl error. Rather than invest in a SCSI controller and burner, I'm going to get this damn drive working for me. I know the problem is a software one, since if I try to burn the raw audio data as a data disc, it works just fine. Furthermore, I had it working under Linux with SCSI emulation. Hunting through burncd.c, I see that the "audio" or "raw" option defines the integer datablock_type as CDR_DB_RAW in the structure cdr_track in /usr/include/sys/cdrio.h (CDR_DB_RAW is defined there as well). CDR_DB_RAW corresponds with blocks of 2352 blocks of raw data. Clearly this doesn't work. I've found other CDR_DB_RAW defines in cdrio.h, as follows: #define CDR_DB_RAW 0x0 /* 2352 bytes of raw data */ #define CDR_DB_RAW_PQ 0x1 /* 2368 bytes raw data + P/Q subchan */ #define CDR_DB_RAW_PW 0x2 /* 2448 bytes raw data + P-W subchan */ #define CDR_DB_RAW_PW_R 0x3 /* 2448 bytes raw data + P-W raw sub */ Would any of these make a better selection for the burncd "audio" or "raw" directives? I'm sorry, but I know nothing of the structure of audio CDs. Any help would be greatly appreciated, and I would, of course, submit any patches I make. -- Andrew Hesford ajh3@chmod.ath.cx To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 8 12:13:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from scribble.fsn.hu (scribble.fsn.hu [193.224.40.95]) by hub.freebsd.org (Postfix) with SMTP id 72CA037B42C for ; Sun, 8 Apr 2001 12:13:17 -0700 (PDT) (envelope-from bra@fsn.hu) Received: (qmail 47009 invoked by uid 1000); 8 Apr 2001 19:13:15 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 8 Apr 2001 19:13:15 -0000 Date: Sun, 8 Apr 2001 21:13:15 +0200 (CEST) From: Attila Nagy To: Subject: Mounting partitions with RO flag Message-ID: <20010408210425.J45749-100000@scribble.fsn.hu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, I have a really stupid question, so please forgive me if the answer is trivial for you... With the appearing of the jail() in 4.0 I think it would be very good to have the functionality of mounting already mounted (RW) filesystems read only to another directory. For example there are several daemons which can run on a read only filesystem, like an anonymous FTP daemon for extra security in a jail. nullfs and unionfs would be suitable for these tasks but they have problems in at least -STABLE, so there are only hacks for doing this, like NFS mounted filesystems and partition "magic" (defining a lot of partitions onto the same physical space). So I am wondering, why the unices block mounting an already mounted partition read only again. Would it be possible to solve this under FreeBSD? Thanks, -------------------------------------------------------------------------- Attila Nagy e-mail: Attila.Nagy@fsn.hu Budapest Polytechnic (BMF.HU) @work: +361 210 1415 (194) H-1084 Budapest, Tavaszmezo u. 15-17. cell.: +3630 306 6758 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 8 13:16:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by hub.freebsd.org (Postfix) with ESMTP id AFEA037B42C for ; Sun, 8 Apr 2001 13:16:46 -0700 (PDT) (envelope-from babolo@links.ru) Received: (from babolo@localhost) by aaz.links.ru (8.9.3/8.9.3) id AAA16747; Mon, 9 Apr 2001 00:16:23 +0400 (MSD) Message-Id: <200104082016.AAA16747@aaz.links.ru> Subject: Re: Mounting partitions with RO flag In-Reply-To: <20010408210425.J45749-100000@scribble.fsn.hu> from "Attila Nagy" at "Apr 8, 1 09:13:15 pm" To: bra@fsn.hu (Attila Nagy) Date: Mon, 9 Apr 2001 00:16:22 +0400 (MSD) Cc: freebsd-hackers@FreeBSD.ORG From: .@babolo.ru MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Attila Nagy writes: > I have a really stupid question, so please forgive me if the answer is > trivial for you... > > With the appearing of the jail() in 4.0 I think it would be very good to > have the functionality of mounting already mounted (RW) filesystems read > only to another directory. > > For example there are several daemons which can run on a read only > filesystem, like an anonymous FTP daemon for extra security in a jail. > > nullfs and unionfs would be suitable for these tasks but they have > problems in at least -STABLE, so there are only hacks for doing this, like > NFS mounted filesystems and partition "magic" (defining a lot of > partitions onto the same physical space). > > So I am wondering, why the unices block mounting an already mounted > partition read only again. > > Would it be possible to solve this under FreeBSD? I am second for it. I am using some partition "magic" and know dark side of it. > -------------------------------------------------------------------------- > Attila Nagy e-mail: Attila.Nagy@fsn.hu > Budapest Polytechnic (BMF.HU) @work: +361 210 1415 (194) > H-1084 Budapest, Tavaszmezo u. 15-17. cell.: +3630 306 6758 -- @BABOLO http://links.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 8 13:24:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from scribble.fsn.hu (scribble.fsn.hu [193.224.40.95]) by hub.freebsd.org (Postfix) with SMTP id DA73137B424 for ; Sun, 8 Apr 2001 13:24:10 -0700 (PDT) (envelope-from bra@fsn.hu) Received: (qmail 47424 invoked by uid 1000); 8 Apr 2001 20:24:09 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 8 Apr 2001 20:24:09 -0000 Date: Sun, 8 Apr 2001 22:24:09 +0200 (CEST) From: Attila Nagy To: <.@babolo.ru> Cc: Subject: Re: Mounting partitions with RO flag In-Reply-To: <200104082016.AAA16747@aaz.links.ru> Message-ID: <20010408222153.O47272-100000@scribble.fsn.hu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, > > Would it be possible to solve this under FreeBSD? > I am second for it. I hope somebody will enlighten my dark mind, because I am really curious about this :) > I am using some partition "magic" and know dark side of it. What the problem is with it besides the ugly hacking and the small number of possible partitions? -------------------------------------------------------------------------- Attila Nagy e-mail: Attila.Nagy@fsn.hu Budapest Polytechnic (BMF.HU) @work: +361 210 1415 (194) H-1084 Budapest, Tavaszmezo u. 15-17. cell.: +3630 306 6758 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 8 14:16:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by hub.freebsd.org (Postfix) with ESMTP id CB88637B422 for ; Sun, 8 Apr 2001 14:16:21 -0700 (PDT) (envelope-from babolo@links.ru) Received: (from babolo@localhost) by aaz.links.ru (8.9.3/8.9.3) id BAA20070; Mon, 9 Apr 2001 01:16:02 +0400 (MSD) Message-Id: <200104082116.BAA20070@aaz.links.ru> Subject: Re: Mounting partitions with RO flag In-Reply-To: <20010408222153.O47272-100000@scribble.fsn.hu> from "Attila Nagy" at "Apr 8, 1 10:24:09 pm" To: bra@fsn.hu (Attila Nagy) Date: Mon, 9 Apr 2001 01:16:02 +0400 (MSD) Cc: freebsd-hackers@FreeBSD.ORG From: .@babolo.ru MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Attila Nagy writes: > > > Would it be possible to solve this under FreeBSD? > > I am second for it. > I hope somebody will enlighten my dark mind, because I am really curious > about this :) > > > I am using some partition "magic" and know dark side of it. > What the problem is with it besides the ugly hacking and the small number > of possible partitions? How much partitions do you want? adNs[0..30][a..h] 31*8= 248 if it is low enough, just use vn[0..]s[0..30][a..h] ... with some more dark sides, of cause About dark side: 0garkin~(4)#df Filesystem 1K-blocks Used Avail Capacity Mounted on ... /dev/ad0s2h 7993324 461995 6891864 6% /usr .... /dev/ad0s3a 7993324 441159 6912700 6% /jail/pent/usr .... There is physically the same fs marked as /dev/ad0s2h and /dev/ad0s3a in this example. The /usr is rw mounted and /jail/pent/usr is ro mounted. Do you see a difference? You can really stuck VM system with ro mount that is really rw mount in another mount. Instances of shared fs do not share buffers - which IS a real point - just allow second mount does not solve a problem IMHO The only way of use this method of fs sharing in production is ro mount of any instance and do not upgrade without all jails stopped. And a lot of memory for files buffers :-( -- @BABOLO http://links.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 8 15:11:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by hub.freebsd.org (Postfix) with ESMTP id 1BA5437B422 for ; Sun, 8 Apr 2001 15:11:25 -0700 (PDT) (envelope-from jazepeda@pacbell.net) Received: from zippy.mybox.zip ([207.214.149.184]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0GBH00K48UYQWH@mta6.snfc21.pbi.net> for hackers@freebsd.org; Sun, 8 Apr 2001 15:11:15 -0700 (PDT) Received: by zippy.mybox.zip (Postfix, from userid 1000) id DA32A188C; Sun, 08 Apr 2001 15:11:08 -0700 (PDT) Date: Sun, 08 Apr 2001 15:11:08 -0700 From: Alex Zepeda Subject: Re: Mounting partitions with RO flag In-reply-to: <20010408210425.J45749-100000@scribble.fsn.hu>; from bra@fsn.hu on Sun, Apr 08, 2001 at 09:13:15PM +0200 To: Attila Nagy , hackers@freebsd.org Message-id: <20010408151108.A1159@zippy.mybox.zip> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <20010408210425.J45749-100000@scribble.fsn.hu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Apr 08, 2001 at 09:13:15PM +0200, Attila Nagy wrote: > So I am wondering, why the unices block mounting an already mounted > partition read only again. Have you considered using ACLs perhaps? Sure it's not in -STABLE, but it's a thought.. - alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 8 22:51:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from muscle.twistedcircus.org (cr171252-a.poco1.bc.wave.home.com [24.113.93.54]) by hub.freebsd.org (Postfix) with ESMTP id 3FDFA37B423 for ; Sun, 8 Apr 2001 22:51:18 -0700 (PDT) (envelope-from cbond@muscle.twistedcircus.org) Received: (from cbond@localhost) by muscle.twistedcircus.org (8.11.2/8.11.2) id f395rLL12669 for freebsd-hackers@freebsd.org; Sun, 8 Apr 2001 22:53:21 -0700 (PDT) (envelope-from cbond) Date: Sun, 8 Apr 2001 22:53:20 -0700 From: "Chris L. Bond" To: freebsd-hackers@freebsd.org Subject: [PATCH] Automatic string allocation for scanf() family Message-ID: <20010408225320.A8157@twistedcircus.org> Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Perhaps not in the true Unix spirit of fixed-size buffers, I've written a patch to add automatic storage allocation to the scanf() family of functions when dealing with strings. I later found out that GNU had a very similar interface in its glibc scanf() functions and made sure that behavior was similar in an effort to maximize portability. The result is attached. With this patch, something like this is now possible: char *buf; sscanf(string, "%as bar", &buf); or sscanf(string, "%a[^ ]", &buf); (providing string was "foo bar", buf would now contain "foo"). Resulting strings can be freed by free(3). The only difference between my implementation and the one in GNU libc is that glibc will return with an error if one of the stdlib memory allocation functions fails, whereas this will continue to run through the string and simply place a NULL at the address where the resulting string would normally have gone. This could be changed if one were so inclined. If this sort of thing is frowned upon for whatever reason, feel free to ignore this message -- I just thought it may be useful. (By the way, this patch is meant for RELENG_4, not HEAD.) --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="vfscanf-as.patch" --- /usr/src/lib/libc/stdio/vfscanf.c.orig Sun Apr 8 21:19:16 2001 +++ /usr/src/lib/libc/stdio/vfscanf.c Sun Apr 8 21:19:21 2001 @@ -69,6 +69,7 @@ #define SUPPRESS 0x08 /* suppress assignment */ #define POINTER 0x10 /* weird %p pointer (`fake hex') */ #define NOSKIP 0x20 /* do not skip blanks */ +#define ALLOC 0x800 /* allocate space for string assignment */ #define QUAD 0x400 /* @@ -170,6 +171,9 @@ case 'L': flags |= LONGDBL; goto again; + case 'a': + flags |= ALLOC; + goto again; case 'h': flags |= SHORT; goto again; @@ -361,7 +365,7 @@ if (flags & SUPPRESS) { n = 0; while (ccltab[*fp->_p]) { - n++, fp->_r--, fp->_p++; + n++, nread++, fp->_r--, fp->_p++; if (--width == 0) break; if (fp->_r <= 0 && __srefill(fp)) { @@ -373,10 +377,32 @@ if (n == 0) goto match_failure; } else { - p0 = p = va_arg(ap, char *); + if (flags & ALLOC) { + /* + * 64 is optimistic. If malloc fails, + * we'll skip this string as if SUPPRESS + * was set in ``flags." + */ + n = 64; + p0 = p = (char *)malloc(n); + } else + p0 = p = va_arg(ap, char *); + while (ccltab[*fp->_p]) { fp->_r--; - *p++ = *fp->_p++; + if (p0) + *p++ = *fp->_p; + fp->_p++, nread++; + if (flags & ALLOC && p0 && p == p0 + n){ + size_t p0_off = p - p0; + /* + * Retain the offset of p, and + * reallocate p0. + */ + n += 64; + p0 = (char *)reallocf(p0, n); + p = p0 + p0_off; + } if (--width == 0) break; if (fp->_r <= 0 && __srefill(fp)) { @@ -385,13 +411,14 @@ break; } } - n = p - p0; - if (n == 0) + if (p == p0) goto match_failure; - *p = 0; + if (p0) + *p = 0; + if (flags & ALLOC) + *va_arg(ap, char **) = p0; nassigned++; } - nread += n; nconversions++; break; @@ -410,17 +437,36 @@ } nread += n; } else { - p0 = p = va_arg(ap, char *); + if (flags & ALLOC) { + n = 64; + p0 = p = (char *)malloc(n); + } else + p0 = p = va_arg(ap, char *); + while (!isspace(*fp->_p)) { fp->_r--; - *p++ = *fp->_p++; + if (p0) + *p++ = *fp->_p; + fp->_p++, nread++; + if (flags & ALLOC && p0 && p == p0 + n){ + size_t p0_off = p - p0; + /* + * We ran out of buffer; + * reallocate. + */ + n += 64; + p0 = (char *)reallocf(p0, n); + p = p0 + p0_off; + } if (--width == 0) break; if (fp->_r <= 0 && __srefill(fp)) break; } - *p = 0; - nread += p - p0; + if (p0) + *p = 0; + if (flags & ALLOC) + *va_arg(ap, char **) = p0; nassigned++; } nconversions++; --- /usr/src/lib/libc/stdio/scanf.3.orig Sun Apr 8 22:37:14 2001 +++ /usr/src/lib/libc/stdio/scanf.3 Sun Apr 8 22:26:18 2001 @@ -174,6 +174,12 @@ (This type is not implemented; the .Cm L flag is currently ignored.) +.It Cm a +(Applicable only to string conversions; see below.) Indicates that storage for +any resulting string should be retrieved automatically. The next pointer must +be a pointer to a string +.Em ( "char *" ) ; +a pointer to the newly allocated storage will be placed at this address. .It Cm q Indicates either that the conversion will be one of .Cm dioux --9jxsPFA5p3P2qPhR-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 8 22:58:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from jason.argos.org (64-205-228-106.client.dsl.net [64.205.228.106]) by hub.freebsd.org (Postfix) with ESMTP id 8900437B422 for ; Sun, 8 Apr 2001 22:58:09 -0700 (PDT) (envelope-from mike@jason.argos.org) Received: (from mike@localhost) by jason.argos.org (8.10.1/8.10.1) id f395upa31117; Mon, 9 Apr 2001 01:56:51 -0400 Date: Mon, 9 Apr 2001 01:56:51 -0400 From: Mike Nowlin To: Jon Molin Cc: freebsd-hackers@freebsd.org Subject: Re: Adding a new drive Message-ID: <20010409015651.A31037@argos.org> References: <3ACD6E95.9AF73435@resfeber.se> <20010406033218.B15254@argos.org> <3ACD7CF3.3C9490E8@resfeber.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3ACD7CF3.3C9490E8@resfeber.se>; from jon.molin@resfeber.se on Fri, Apr 06, 2001 at 10:23:15AM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 0, Jon Molin wrote: > Wrote FDISK partition information out successfully.=20 >=20 > After that i quit back to config menu, goes into label and there i just d= o an > 'auto' to see if it works, there i get the following when i write: > Unable to add /dev/ad3s1b as a swap device: Device not configured > and similar errors for the rest of the partitions.=20 Out of curiosity, and because I have this annoying itch in my brain that's telling me I ran into this problem recently: Are the entries for ad3* actually in /dev? I recall having to ./MAKEDEV them for the ad2 and ad3 disks on one of my machines that I added a drive to not more than a couple of weeks ago... Depending on how disklabel works, I could see it returning the "Device not configured" message if the /dev file isn't there... mike --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjrRTyIACgkQJol4I8h9Gd9pyQCgtVh9E+G8i6XwpdX1upy6jDCk r3wAmwf+A1ukmDsAixHo/0XMjO9CM0Pg =h9Gn -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 9 1:18:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from scribble.fsn.hu (scribble.fsn.hu [193.224.40.95]) by hub.freebsd.org (Postfix) with SMTP id 6E77B37B422 for ; Mon, 9 Apr 2001 01:18:13 -0700 (PDT) (envelope-from bra@fsn.hu) Received: (qmail 51890 invoked by uid 1000); 9 Apr 2001 08:18:12 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 9 Apr 2001 08:18:12 -0000 Date: Mon, 9 Apr 2001 10:18:12 +0200 (CEST) From: Attila Nagy To: Alex Zepeda Cc: Subject: Re: Mounting partitions with RO flag In-Reply-To: <20010408151108.A1159@zippy.mybox.zip> Message-ID: <20010409101551.C51546-100000@scribble.fsn.hu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, > > So I am wondering, why the unices block mounting an already mounted > > partition read only again. > Have you considered using ACLs perhaps? Sure it's not in -STABLE, but > it's a thought.. It's a good thing, but I need to solve this problem on -STABLE, not on -CURRENT :( I think running -CURRENT on a production machine is not a good idea... Thanks, -------------------------------------------------------------------------- Attila Nagy e-mail: Attila.Nagy@fsn.hu Budapest Polytechnic (BMF.HU) @work: +361 210 1415 (194) H-1084 Budapest, Tavaszmezo u. 15-17. cell.: +3630 306 6758 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 9 3:29:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 5C3C237B424 for ; Mon, 9 Apr 2001 03:29:06 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 8745 invoked by uid 1000); 9 Apr 2001 10:27:50 -0000 Date: Mon, 9 Apr 2001 13:27:49 +0300 From: Peter Pentchev To: =?windows-1251?B?qkytXrZX?= Cc: Freebsd-Hackers Subject: Re: Who call setitimer( )? Message-ID: <20010409132749.A62577@ringworld.oblivion.bg> Mail-Followup-To: =?windows-1251?B?qkytXrZX?= , Freebsd-Hackers References: <200104071907.DAA07463@cslab.csie.ntu.edu.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <200104071907.DAA07463@cslab.csie.ntu.edu.tw>; from r88074@csie.ntu.edu.tw on Sun, Apr 08, 2001 at 03:07:25AM +0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Apr 08, 2001 at 03:07:25AM +0800, ªL­^¶W wrote: > Dear all: > I trace the FreeBSD kernel source , and I can't find program call the > function "setitimer()", > > Is it a callout function to call it ? I will appreciate if anyone give > me some advice setitimer() is defined in sys/kern/kern_time.c. If you're looking for parts of the kernel that *call* setitimer(), well, there aren't too many of those (except for the Linux/SVR4/OSF emulators) - setitimer() is a system call, designed to be called from userland programs. man 2 setitimer for more details. G'luck, Peter -- I had to translate this sentence into English because I could not read the original Sanskrit. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 9 4:40:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from hotmail.com (f28.pav1.hotmail.com [64.4.31.28]) by hub.freebsd.org (Postfix) with ESMTP id 5D07D37B423 for ; Mon, 9 Apr 2001 04:40:44 -0700 (PDT) (envelope-from samrat000@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 9 Apr 2001 04:40:43 -0700 Received: from 203.200.171.38 by pv1fd.pav1.hotmail.msn.com with HTTP; Mon, 09 Apr 2001 11:40:43 GMT X-Originating-IP: [203.200.171.38] From: "samrat basuthakur" To: freebsd-hackers@FreeBSD.org Date: Mon, 09 Apr 2001 11:40:43 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Apr 2001 11:40:43.0538 (UTC) FILETIME=[E9000720:01C0C0E9] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG let me know about you peoples and your website. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 9 6:25:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 118D537B423 for ; Mon, 9 Apr 2001 06:25:43 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 758 invoked by uid 1000); 9 Apr 2001 13:24:23 -0000 Date: Mon, 9 Apr 2001 16:24:23 +0300 From: Peter Pentchev To: samrat basuthakur Cc: freebsd-hackers@FreeBSD.org Subject: Re: your mail Message-ID: <20010409162423.A681@ringworld.oblivion.bg> Mail-Followup-To: samrat basuthakur , freebsd-hackers@FreeBSD.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from samrat000@hotmail.com on Mon, Apr 09, 2001 at 11:40:43AM -0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Apr 09, 2001 at 11:40:43AM -0000, samrat basuthakur wrote: > let me know about you peoples and your website. Us, we're just a bunch of weenies high on LS^H^HBSD, and the website's www.FreeBSD.org, thanks for your attention :) G'luck, Peter -- I've heard that this sentence is a rumor. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 9 8:40:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 889F037B422 for ; Mon, 9 Apr 2001 08:40:12 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (bill.cs.rpi.edu [128.213.2.2]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id LAA52639 for ; Mon, 9 Apr 2001 11:40:12 -0400 (EDT) Message-Id: <200104091540.LAA52639@cs.rpi.edu> To: freebsd-hackers@freebsd.org Subject: sigh... ypserv bug still very much alive Date: Mon, 09 Apr 2001 11:40:11 -0400 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The ypserv bug (the one where ypserv randomly stops responding or just seg-faults) is still very much alive. I had to restart it about 11 times in the course of 20 minutes this morning. That's the bad news, the good news is that I started it each time with 'ktrace -i'. Going back a bit, Matt Dillon suggested that the problem may have been in the signal handler for sigchld. I looked at the signal handler and it does not appear to be doing anything dangerous at all (just a child_count--;) is it doing something dangerous that I am just not seeing? Also, in the last 200 lines of kdump output for each and every crash there is the sequence of calls "select(); gettimeofday();"... that sequence of calls never appears in the ypserv source code, but does appear in svc_tcp.c in librpc... my question is: "ypserv defines its own svc_run, and for TCP connections specifically handles things itself very carefully, how is the svc_tcp.c code getting called at all?" I think the answer to that is the source of the problem (it should also be noted that in the case where ypserv hasn't died and I have collected ktrace information -- up to 8 gig of it -- the "select(); gettimeofday();" sequence is _never_ called.) One of my ktrace-s is _very_ small, only 330K, from fork()/exec() to SIG_DFL/SEGV, so I am hoping this will provide easily digestible information. I did not include context-switch information in the ktrace for the following reasons: 1) It didn't appear to be usefull, and since I did specify the -i, it is obvious where context switches occur (to the only thing that could affect anything: the children) 2) It caused ypserv to act strangely... instead of dying, it just got very slow, and didn't respond. Anyone interested in helping me track this one down? -- David Cross | email: crossd@cs.rpi.edu Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 9 10:59:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from xena.gsicomp.on.ca (cr677933-a.ktchnr1.on.wave.home.com [24.43.230.149]) by hub.freebsd.org (Postfix) with ESMTP id 46F9237B424 for ; Mon, 9 Apr 2001 10:59:32 -0700 (PDT) (envelope-from matt@gsicomp.on.ca) Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18]) by xena.gsicomp.on.ca (8.11.1/8.11.3) with SMTP id f39HvdR23338; Mon, 9 Apr 2001 13:57:39 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <001a01c0c11e$28300830$1200a8c0@gsicomp.on.ca> From: "Matthew Emmerton" To: , "David E. Cross" References: <200104091540.LAA52639@cs.rpi.edu> Subject: Re: sigh... ypserv bug still very much alive Date: Mon, 9 Apr 2001 13:54:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The ypserv bug (the one where ypserv randomly stops responding or > just seg-faults) is still very much alive. I had to restart it > about 11 times in the course of 20 minutes this morning. That's > the bad news, the good news is that I started it each time with > 'ktrace -i'. > > Also, in the last 200 lines of kdump output for each and every crash there > is the sequence of calls "select(); gettimeofday();"... that sequence of > calls never appears in the ypserv source code, but does appear in svc_tcp.c > in librpc... my question is: "ypserv defines its own svc_run, and for > TCP connections specifically handles things itself very carefully, how is > the svc_tcp.c code getting called at all?" I think the answer to that is > the source of the problem (it should also be noted that in the case where > ypserv hasn't died and I have collected ktrace information -- up to 8 gig > of it -- the "select(); gettimeofday();" sequence is _never_ called.) I have virtually no experience with RPC or YP/NIS, but I can trace code. Here's what I found: Case #1 usr.sbin/ypserv/ypserv.c : main() calls svctcp_create() lib/libc/rpc/svc_tcp.c : svctcp_create() returns an SVCXPRT with a reference to an initialized rendezvous handler That in itself seems fine, but a rendezvous_request() op on the rendezvous handler can trigger the problem: lib/libc/rpc/svc_tcp.c : rendezvous_request() calls makefd_xprt() lib/libc/rpc/svc_tcp.c : makefd_xprt() calls xdrrec_create() with a pointer to readtcp() lib/libc/rpc/svc_tcp.c : readtcp() calls select(), gettimeofday() Case #2 usr.sbin/ypserv/ypserv.c : main() calls svc_register() lib/libc/rpc/svc_tcp.c : svc_register() calls pmap_set() lib/libc/rpc/pmap_clnt.c: pmap_set() *may* call clnt_create() lib/libc/rpc/clnt_generic.c : clnt_create() calls clnttcp_create() lib/libc/rpc/svc_tcp.c : clnttcp_create() calls readtcp() lib/libc/rpc/svc_tcp.c : readtcp() calls select(), gettimeofday() In answer to your question about "how is the svc_tcp.c code getting called at all?": In case #1, it's getting called when main() starts up and creates the initial TCP listener. In case #2, it's getting called when main() registers the services. Hopefully this will aid you (and others) in tracking down this problem. -- Matt Emmerton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 9 20:16:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from stox.sa.enteract.com (stox.sa.enteract.com [207.229.132.161]) by hub.freebsd.org (Postfix) with ESMTP id 71BF337B43F for ; Mon, 9 Apr 2001 20:16:39 -0700 (PDT) (envelope-from stox@stox.sa.enteract.com) Received: (from stox@localhost) by stox.sa.enteract.com (8.11.3/8.11.3) id f3A3GWW01108; Mon, 9 Apr 2001 22:16:33 -0500 (CDT) (envelope-from stox) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010408210425.J45749-100000@scribble.fsn.hu> Date: Mon, 09 Apr 2001 22:16:27 -0500 (CDT) Organization: Imaginary Landscape, LLC. From: "Kenneth P. Stox" To: Attila Nagy Subject: RE: Mounting partitions with RO flag Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 08-Apr-01 Attila Nagy wrote: > So I am wondering, why the unices block mounting an already mounted > partition read only again. > > Would it be possible to solve this under FreeBSD? Loopback NFS mount, maybe ? ---------------------------------- E-Mail: Kenneth P. Stox Date: 09-Apr-01 Time: 22:15:31 ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 1:34:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail2.resfeber.se (Resfeber-gw.customer.internet5.net [195.66.48.230]) by hub.freebsd.org (Postfix) with ESMTP id ACA4D37B422 for ; Tue, 10 Apr 2001 01:34:07 -0700 (PDT) (envelope-from jon.molin@resfeber.se) Received: from resfeber.se ([212.75.72.9]) by mail2.resfeber.se (8.9.3/8.9.3) with ESMTP id KAA14905 for ; Tue, 10 Apr 2001 10:25:41 +0200 Message-ID: <3AD2C61F.E9F8EF1E@resfeber.se> Date: Tue, 10 Apr 2001 10:36:47 +0200 From: Jon Molin X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: Re: Adding a new drive References: <3ACD6E95.9AF73435@resfeber.se> <20010406030353.A28772@cec.wustl.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Andrew Hesford wrote: > > On Fri, Apr 06, 2001 at 10:17:24AM +0200, Jon Molin wrote: > > The -I option gives the same output: > > jmo# fdisk -I ad3 > > ******* Working on device /dev/ad3 ******* > > fdisk: invalid fdisk partition table found > > jmo# disklabel -B -w -r ad3s1 auto > > disklabel: /dev/ad3s1: Device not configured > > > > /jon > > [snip] > Why don't you try this: re-zero the device, just to make sure it's > clean, then give fdisk another go. If it fails, re-zero it again, and > try to use Windows fdisk (or even Linux) to partition the drive. If > neither one succeeds, you know the disk got trashed, and your failure is > most likely a coincidence. If one *does* succeed, then save the MBR, put > the disk in your FreeBSD box, and edit the existing MBR with the FreeBSD > fdisk. > -- > Andrew Hesford > ajh3@chmod.ath.cx When i first got the disk it was windows and i was able to mount and get the data from it. Then i used freebsd fdisk and all 'dispeared'. Then i used a slackware bootdisk to get fdisk there and was able to make it a bsd partition, but when i booted back to freebsd and tried to slice it it didn't work... And i got the devices there: # ls /dev/ad3* /dev/ad3 /dev/ad3e /dev/ad3s1a /dev/ad3s1f /dev/ad3s4 /dev/ad3a /dev/ad3f /dev/ad3s1b /dev/ad3s1g /dev/ad3b /dev/ad3g /dev/ad3s1c /dev/ad3s1h /dev/ad3c /dev/ad3h /dev/ad3s1d /dev/ad3s2 /dev/ad3d /dev/ad3s1 /dev/ad3s1e /dev/ad3s3 /jon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 2:49:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.viasoft.com.cn (unknown [61.153.1.177]) by hub.freebsd.org (Postfix) with ESMTP id D5DA137B423 for ; Tue, 10 Apr 2001 02:49:47 -0700 (PDT) (envelope-from bsddiy@21cn.com) Received: from William ([192.168.1.98]) by mail.viasoft.com.cn (8.9.3/8.9.3) with ESMTP id RAA13852 for ; Tue, 10 Apr 2001 17:47:25 +0800 Date: Tue, 10 Apr 2001 17:53:37 +0800 From: David Xu X-Mailer: The Bat! (v1.48f) Personal Reply-To: David Xu Organization: Viasoft X-Priority: 3 (Normal) Message-ID: <16533681351.20010410175337@21cn.com> To: freebsd-hackers@freebsd.org Subject: vm balance X-Sender: David Xu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I heard NetBSD has implemented a FreeBSD like VM, it also implemented a VM balance in recent verion of NetBSD. some parameters like TEXT, DATA and anonymous memory space can be tuned. is there anyone doing such work on FreeBSD or has FreeBSD already implemented it? -- David Xu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 5:40:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from firewall.moonworld.org (dsl-64-34-46-105.telocity.com [64.34.46.105]) by hub.freebsd.org (Postfix) with ESMTP id 96E8437B422 for ; Tue, 10 Apr 2001 05:40:05 -0700 (PDT) (envelope-from moonhunt@moonworld.org) Received: from moonworld.org (moonhunt.moonworld.org [192.168.1.1]) by firewall.moonworld.org (8.9.3/8.9.3) with ESMTP id HAA64581 for ; Tue, 10 Apr 2001 07:37:03 -0500 (CDT) (envelope-from moonhunt@moonworld.org) Message-ID: <3AD2FF23.239CD9DF@moonworld.org> Date: Tue, 10 Apr 2001 07:40:03 -0500 From: HyunSeog Ryu Reply-To: r.hyunseog@ieee.org Organization: Moon world X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en,ko MIME-Version: 1.0 To: hackers@freebsd.org Subject: Interesting article. Content-Type: multipart/mixed; boundary="------------723A107D92DEF8CD987C42E2" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------723A107D92DEF8CD987C42E2 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit Hi, folks Today I got email from Microsoft regarding hotmail migration. . Migrating Microsoft® Hotmail® from FreeBSD to Microsoft Windows® 2000 Technical Case Study http://www.microsoft.com/technet/migration/hotmail/default.asp If you have free time, enjoy M$'s wonderful marketing power. :-( Hyun --------------723A107D92DEF8CD987C42E2 Content-Type: text/x-vcard; charset=EUC-KR; name="moonhunt.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for HyunSeog Ryu Content-Disposition: attachment; filename="moonhunt.vcf" begin:vcard n:Ryu;HyunSeog tel;pager:(414)557-2253 tel;fax:(262)792-7733 tel;work:(262)792-7965 x-mozilla-html:FALSE url:http://www.moonworld.org/~moonhunt org:Norlight Telecommunications;Applications Engineering adr:;;275 North Corporate Drive;Brookfield;WI;53045-5818;US version:2.1 email;internet:r.hyunseog@ieee.org title:Network Engineer note;quoted-printable:nic-handile : HR201, HR201-ARIN, HR1-APNIC and work for AS#7260=0D=0A fn:HyunSeog Ryu end:vcard --------------723A107D92DEF8CD987C42E2-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 7:21:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tango.entreri.com (tango.entreri.com [205.219.158.250]) by hub.freebsd.org (Postfix) with ESMTP id 75FCB37B424 for ; Tue, 10 Apr 2001 07:21:46 -0700 (PDT) (envelope-from dp@penix.org) Received: from penix.org (Toronto-ppp221209.sympatico.ca [64.228.106.26]) by tango.entreri.com (8.10.2/8.9.1) with ESMTP id f3AELbx06171 for ; Tue, 10 Apr 2001 09:21:38 -0500 Message-ID: <3AD319C0.7D273729@penix.org> Date: Tue, 10 Apr 2001 10:33:36 -0400 From: Paul Halliday X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org Subject: re: windows tech article? Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Taken from: http://www.microsoft.com/technet/migration/hotmail/default.asp "FreeBSD, a UNIX-like system similar to the Linux operating system, was used to run the front-end Web servers that handled login, Microsoft Outlook® Express, and Web-based content delivery tasks" Is it just me or is this statement completely incorrect? A "Unix-like system" I always thought It was UNIX. Similar to Linux? I always believed that Linux was well, anything but UNIX. I also fail to see any similarities between FreeBSD and Linux. Maybe they should have said: "FreeBSD, an advanced BSD UNIX operating system, which you should not confuse with the silly penguin warez available, was used to run the front-end Web servers that handled login, Microsoft Outlook® Express, and Web-based content delivery tasks. We decided that because we leech all the information that passes though these servers anyway, that we may as well use M$ Windows 2000 server, a patched yet still buggy version of Windows 3.1. Everyone expects Mircosoft products to be unstable and they pay us to be beta testers so why break the trend. ;P -- Paul Halliday ============================================================================ Don't underestimate the power of stupid people in large groups. Web: http://dp.penix.org Current Project: http://www3.sympatico.ca/transmogrify/cl.html Public Key available here: http://dp.penix.org/dp.txt ============================================================================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 7:23:17 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from newgold.net (durham0-128.dsl.gtei.net [4.3.0.128]) by hub.freebsd.org (Postfix) with SMTP id 5BBF337B422 for ; Tue, 10 Apr 2001 07:23:02 -0700 (PDT) (envelope-from jmallett@newgold.net) Received: (qmail 20876 invoked by uid 1000); 10 Apr 2001 14:22:10 -0000 Date: Tue, 10 Apr 2001 10:22:10 -0400 (EDT) From: Joseph Mallett To: Paul Halliday Cc: hackers@freebsd.org Subject: re: windows tech article? In-Reply-To: <3AD319C0.7D273729@penix.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I didn't know you were allowed to say "warez" on hackers@ /joseph -- Joseph Mallett Security Specialist jmallett@newgold.net www.newgold.net irc.newgold.net/#xMach xMach Core Team jmallett@xMach.org www.xMach.org On Tue, 10 Apr 2001, Paul Halliday wrote: > Taken from: > http://www.microsoft.com/technet/migration/hotmail/default.asp >=20 > "FreeBSD, a UNIX-like system similar to the Linux operating system, was > used to run the front-end Web servers that=20 > handled login, Microsoft Outlook=AE Express, and Web-based content > delivery tasks" >=20 > =09Is it just me or is this statement completely incorrect? A "Unix-like > system" I always thought It was UNIX. Similar to Linux? I always > believed that Linux was well, anything but UNIX.=20 >=20 > =09I also fail to see any similarities between FreeBSD and Linux. >=20 > Maybe they should have said: "FreeBSD, an advanced BSD UNIX operating > system, which you should not confuse with the silly penguin warez > available, was used to run the front-end Web servers that handled login, > Microsoft Outlook=AE Express, and Web-based content delivery tasks. We > decided that because we leech all the information that passes though > these servers anyway, that we may as well use M$ Windows 2000 server, a > patched yet still buggy version of Windows 3.1. Everyone expects > Mircosoft products to be unstable and they pay us to be beta testers so > why break the trend. >=20 > ;P >=20 > --=20 > Paul Halliday > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > Don't underestimate the power of stupid people in large groups. > Web: http://dp.penix.org > Current Project: http://www3.sympatico.ca/transmogrify/cl.html > Public Key available here: http://dp.penix.org/dp.txt > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 7:44:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id C376437B423 for ; Tue, 10 Apr 2001 07:44:10 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3AEigf71345; Tue, 10 Apr 2001 10:44:43 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 10 Apr 2001 10:44:42 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Attila Nagy Cc: freebsd-hackers@freebsd.org Subject: Re: Mounting partitions with RO flag In-Reply-To: <20010408210425.J45749-100000@scribble.fsn.hu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 8 Apr 2001, Attila Nagy wrote: > With the appearing of the jail() in 4.0 I think it would be very good to > have the functionality of mounting already mounted (RW) filesystems read > only to another directory. Many people agree with you -- this is one reason why the fixing of nullfs in -CURRENT was so desirable. However, most consumers of jail are actually looking to replicate only a portion of their jails--usually the /usr tree, as it's the most sizable chunk, and then symlink bin and sbin into it. This preserves /, /var, /etc, and /tmp as running inside the jail. Jail is really intended to virtualize whole environments, rather than particular daemons, however (doesn't mean you can't, but that was the thrust). > For example there are several daemons which can run on a read only > filesystem, like an anonymous FTP daemon for extra security in a jail. > > nullfs and unionfs would be suitable for these tasks but they have > problems in at least -STABLE, so there are only hacks for doing this, > like NFS mounted filesystems and partition "magic" (defining a lot of > partitions onto the same physical space). > > So I am wondering, why the unices block mounting an already mounted > partition read only again. Well, you certainly don't want to mount the same partition writable and read-only at the same time. It's an arbitrary design choice to prevent simultaneous mounting of read-only file systems on one vnode, and one that I think Poul-Henning was going to look at removing as part of his device layer restructuring. > Would it be possible to solve this under FreeBSD? It seems like there are a number of solutions to the problem that have been considered: nullfs fixed in 5.0-CURRENT nfs loopback works multiple mounting not implemented nullfs is probably the best choice, as it prevents redundant caching in the vm/buffer cache. nfs loopback introduces a substantial performance overhead, but at least works. And multiple mounting won't provide the RW/RO behavior you want, only multiple RO mounts, although it should be straight-forward to implement it. You could hack that in now by futzing with the vfs_mountedon() behavior, it's just not clear it provides what you actually want. The best bet may be to backport the nullfs fixes to 4.x, or to wait for 5.x. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 7:46:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 8B69C37B43C for ; Tue, 10 Apr 2001 07:46:14 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3AEkjf71377; Tue, 10 Apr 2001 10:46:46 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 10 Apr 2001 10:46:45 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Alex Zepeda Cc: Attila Nagy , hackers@freebsd.org Subject: Re: Mounting partitions with RO flag In-Reply-To: <20010408151108.A1159@zippy.mybox.zip> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 8 Apr 2001, Alex Zepeda wrote: > On Sun, Apr 08, 2001 at 09:13:15PM +0200, Attila Nagy wrote: > > > So I am wondering, why the unices block mounting an already mounted > > partition read only again. > > Have you considered using ACLs perhaps? Sure it's not in -STABLE, but > it's a thought.. ACLs are a form of discretionary access control, and as such can't impose mandatory read-only behavior for processes in a jail. For that, you want mandatory access control, a feature still under development as part of TrustedBSD. However, mandatory file labeling substantially complicates file system management, and jail provides a simple substitute by using chroot, a choice that seems wise to me :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 7:53:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 1E5F037B422 for ; Tue, 10 Apr 2001 07:53:44 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3AEsHf71524; Tue, 10 Apr 2001 10:54:17 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 10 Apr 2001 10:54:16 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: r.hyunseog@ieee.org Cc: hackers@freebsd.org Subject: Re: Interesting article. In-Reply-To: <3AD2FF23.239CD9DF@moonworld.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Actually, the most fascinating part of the article for me was footnote 2: F2 - There obviously are multi-tasking/multi-process solutions that Hotmail could have leveraged under FreeBSD. However, they would require making application modifications and rework to implement. So, this was an optimum opportunity to examine other options and platforms. I.e., they could have reimplemented the FreeBSD-based Hotmail using a non-CGI solution on FreeBSD to get much of the performance gain they got by moving to Windows 2000, but since they were going to do the work anyway, why not migrate to Windows 2000 at the same time. Neither CGI on Windows nor on FreeBSD can provide the kind of performance large-scale dynamic content web sites require, and that change probably explains the majority of the performance improvement. Some of the remainder probably comes from pushing large parts of the web server into kernel-space, a design choice that, while gleaning additional performance, may be questionable from a stability and design perspective. One of the interesting pieces of performance work in FreeBSD that has come out of Yahoo! is the introduction of Accept Filters, which allow applications to push some customized behavior into the kernel using a relatively clean interface. It would be interesting to compare the before/after Accept Filter cases with the before/after IIS kernel introduction cases. Given the degree of "stuff" pushed into the kernel under IIS, you might continue to expect a similar or higher level of performance under Windows 2000, especially with their reengineered IP stack under Windows 2000.=20 Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services On Tue, 10 Apr 2001, HyunSeog Ryu wrote: >=20 > Hi, folks >=20 > Today I got email from Microsoft regarding hotmail migration. >=20 > . Migrating Microsoft=AE Hotmail=AE from FreeBSD to Microsoft Windows=AE = 2000 > Technical Case Study =20 > http://www.microsoft.com/technet/migration/hotmail/default.asp=20 >=20 > If you have free time, enjoy M$'s wonderful marketing power. :-( >=20 > Hyun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 8:38:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 52B4237B423 for ; Tue, 10 Apr 2001 08:38:42 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.11.3/8.11.3) id f3AFcWr11630; Tue, 10 Apr 2001 10:38:32 -0500 (CDT) (envelope-from dan) Date: Tue, 10 Apr 2001 10:38:31 -0500 From: Dan Nelson To: Paul Halliday Cc: hackers@FreeBSD.ORG Subject: Re: windows tech article? Message-ID: <20010410103831.B15185@dan.emsphone.com> References: <3AD319C0.7D273729@penix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <3AD319C0.7D273729@penix.org>; from "Paul Halliday" on Tue Apr 10 10:33:36 GMT 2001 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Apr 10), Paul Halliday said: > Taken from: > http://www.microsoft.com/technet/migration/hotmail/default.asp > > "FreeBSD, a UNIX-like system similar to the Linux operating system, > was used to run the front-end Web servers that handled login, > Microsoft Outlook_ Express, and Web-based content delivery tasks" > > Is it just me or is this statement completely incorrect? A "Unix-like > system" I always thought It was UNIX. Similar to Linux? I always > believed that Linux was well, anything but UNIX. Depends on who you expect to be reading the sentence. For non-techies, it is perfect. They have heard of Unix, and know that Linux is one of the more popular unix-type OSes. -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 9: 9:38 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tovaris.com (fw-an0.tovaris.com [209.145.84.34]) by hub.freebsd.org (Postfix) with ESMTP id B1C3C37B423 for ; Tue, 10 Apr 2001 09:09:35 -0700 (PDT) (envelope-from andria@tovaris.com) Received: (qmail 13451 invoked by uid 0); 10 Apr 2001 16:10:08 -0000 Received: from mail.intranet (HELO tovaris.com) (10.0.0.8) by oldmail.intranet with DES-CBC3-SHA encrypted SMTP; 10 Apr 2001 16:10:08 -0000 X-Accept-Language: en X-Mailer: Mozilla 4.73 [en] (X11; I; FreeBSD 4.1-RELEASE i386) From: "Andria Thomas" To: hackers@freebsd.org Date: Tue, 10 Apr 2001 12:09:33 -0400 Message-ID: <3AD3303D.7E01528D@tovaris.com> Subject: problem with Aironet driver MIME-Version: 1.0 Content-Type: TEXT/plain; charset="us-ascii" Content-Transfer-Encoding: 7BIT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi everyone. I'd like to report a problem we've been having with the Aironet driver on two of our machines. One machine is running FreeBSD 4.1.1-RELEASE, and the other is a very recent upgrade to 4.3-RC1. They both have Aironet PCI4800 cards and are connected directly to antennas (one on our roof, one on the roof of our ISP). Recently, we've seen messages like the following spewed to the consoles of each machine: Mar 26 14:25:57 gw /kernel: an0: id mismatch: expected 178, got 224 Mar 26 14:25:57 gw /kernel: an0: id mismatch: expected 17e, got 178 Mar 26 14:25:58 gw /kernel: an0: id mismatch: expected 9e, got 17e Mar 26 14:25:58 gw /kernel: an0: id mismatch: expected 224, got 9e Mar 26 14:25:59 gw /kernel: an0: id mismatch: expected 178, got 224 Mar 26 14:25:59 gw /kernel: an0: id mismatch: expected 17e, got 178 Mar 26 14:25:59 gw /kernel: an0: id mismatch: expected 9e, got 17e Mar 26 14:25:59 gw /kernel: an0: id mismatch: expected 224, got 9e Mar 26 14:26:00 gw /kernel: an0: id mismatch: expected 178, got 224 Mar 26 14:26:01 gw /kernel: an0: id mismatch: expected 17e, got 178 Mar 26 14:26:02 gw /kernel: an0: id mismatch: expected 9e, got 17e Mar 26 14:26:02 gw /kernel: an0: id mismatch: expected 224, got 9e Mar 26 14:26:03 gw /kernel: an0: id mismatch: expected 178, got 224 Mar 26 14:26:03 gw /kernel: an0: id mismatch: expected 17e, got 178 Mar 26 14:26:03 gw /kernel: an0: id mismatch: expected 9e, got 17e Mar 26 14:26:04 gw /kernel: an0: id mismatch: expected 224, got 9e Mar 26 14:26:04 gw /kernel: an0: id mismatch: expected 178, got 224 Mar 26 14:26:04 gw /kernel: an0: id mismatch: expected 17e, got 178 Mar 26 14:26:05 gw /kernel: an0: id mismatch: expected 9e, got 17e Mar 26 14:26:05 gw /kernel: an0: id mismatch: expected 224, got 9e When these messages begin, our network connection grinds to a near-halt (ping times of 1000-2000ms). The only way we've found to stop the messages is to disconnect the Aironet connection, and bring the network interface down and back up again. When it comes back up, everything is mysteriously back to normal. I've tried looking through the source code, but confess to not understanding what it is that prompts these messages to begin. Any help would be greatly appreciated. I've tried poring through mailing list archives, but no one else seems to have reported a similar problem. Thanks for any help you can offer! Andria Thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 10:33:52 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from renown.cnchost.com (renown.concentric.net [207.155.248.7]) by hub.freebsd.org (Postfix) with ESMTP id 88F8F37B424; Tue, 10 Apr 2001 10:33:49 -0700 (PDT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by renown.cnchost.com id NAA09610; Tue, 10 Apr 2001 13:33:41 -0400 (EDT) [ConcentricHost SMTP Relay 1.10] Message-ID: <200104101733.NAA09610@renown.cnchost.com> To: Robert Watson Cc: r.hyunseog@ieee.org, hackers@freebsd.org Subject: Re: Interesting article. In-Reply-To: Your message of "Tue, 10 Apr 2001 10:54:16 EDT." Date: Tue, 10 Apr 2001 10:33:40 -0700 From: Bakul Shah Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From the top level page I read hotmail handles 550,000 change requests a day. Later in the article they say they have a 5000 server farm. That translates to 110 change requests a day on average per server. If the peak rate is 10 times the average, that is still only about 1100 requests/server/day or about 78 seconds on average. This rate seems quite low even when you account for multiple web page servings per change request.... Am I missing something obvious? In http://www.microsoft.com/technet/migration/hotmail/hotdepl.asp they say this: With these major changes and few other minor ones, the number of requests per second that could be handled nearly doubled what the live site was experiencing. Compared to what? FreeBSD servers running perl based cgi scripts? Or converted servers running c++ based scripts? Even if the latter, a mere doubling of performance makes me think very likely they did not look at *all* the hotspots (meaning carefully look at where and how much time is spent for each request on every machine taking part, bandwidth of network and disk etc). And you have to keep looking since hotspots move as you speed things up. Though, a lack of good Unicode support on FreeBSD seems like a legitimate enough reason for the move. Regardless, note that doubling of the performance meant they saved anywhere from $10M to $20M (5000 servers x (price + maintenance of each server) - development and testing costs). Another doubling would still save them $5M or so! I'd take that challenge if I can get 50% of the savings!:-) It would be interesting to see what Yahoo has done for Yahoo mail. -- bakul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 11: 5:18 2001 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id E229D37B422; Tue, 10 Apr 2001 11:05:14 -0700 (PDT) Subject: sendfile() vs. gigabit ethernet To: hackers@freebsd.org Date: Tue, 10 Apr 2001 11:05:14 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20010410180514.E229D37B422@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG People are constantly asking me about the performance of gigabit ethernet cards with FreeBSD. I'm constantly wishing they would all go to hell -- directly to hell, without passing "GO" or collecting $200 -- but their persistence has led me to ask a few questions of my own. One thing everyone notices right away is that some of FreeBSD's defaults aren't terribly optimal for gigabit ethernet, the main one being socket buffer sizes. At least as far as TCP is concerned, you can do one of two things: - Change your application to call setsockopt() and increase the SO_SNDBUF and SO_RCVBUF values. - Use sysctl to change the net.inet.tcp.sendspace and net.inet.tcp.recvspace values. The former option affectly only a given application, while the latter affects the entire system. Most people will bump the sendspace and recvspace variables since it's easier than modifying their application. Changing the default from 16K to 64K usually has a drastic effect on performance with something like ttcp, which is what I typically use for testing. You can also use the -B flag to ttcp to have it increase the SNDBUF/RCVBUF values just for itself and achieve the same effect. But then what usually happens is people will attempt to perform a file transfer test using, of all things. FTP, and suddenly they notice that performance doesn't really improve all that much. I could never understand just why this was so, until I realized that /usr/libexec/ftpd in FreeBSD now uses sendfile(). The ttcp utility on the other hand uses write(2) (as does netperf for that matter). So my question is: has anyone done any tests with sendfile() over a high speed network link and tried to vary the sendspace/recvspace defaults to improve performance? If so, does it make any difference? My feeling is that it should, but from what I can tell, sendfile() only passes data to sosend() in page-sized chunks, and this is somehow negating the effect of increasing the socket buffer size. Am I right, or am I just missing something obvious, as usual? -Bill ============================================================================= -Bill Paul (925) 691-2800 | Systems Programmer, Master of Unix-Fu wpaul@osd.bsdi.com | BSDi Open Source Solutions ============================================================================= "I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 11:27:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id C4C5E37B422 for ; Tue, 10 Apr 2001 11:27:14 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3AIR3H89467; Tue, 10 Apr 2001 11:27:03 -0700 (PDT) (envelope-from dillon) Date: Tue, 10 Apr 2001 11:27:03 -0700 (PDT) From: Matt Dillon Message-Id: <200104101827.f3AIR3H89467@earth.backplane.com> To: David Xu Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance References: <16533681351.20010410175337@21cn.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I heard NetBSD has implemented a FreeBSD like VM, it also implemented :a VM balance in recent verion of NetBSD. some parameters like TEXT, :DATA and anonymous memory space can be tuned. is there anyone doing :such work on FreeBSD or has FreeBSD already implemented it? : :-- :David Xu FreeBSD implements a very sophisticated VM balancing algorithm. Nobody's complaining about it so I don't think we need to really change it. Most of the other UNIXes, including Linux, are actually playing catch-up to FreeBSD's VM design. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 11:32:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id E551F37B422 for ; Tue, 10 Apr 2001 11:32:20 -0700 (PDT) (envelope-from arr@watson.org) Received: from localhost (arr@localhost) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3AIWRr75662; Tue, 10 Apr 2001 14:32:32 -0400 (EDT) (envelope-from arr@watson.org) Date: Tue, 10 Apr 2001 14:32:26 -0400 (EDT) From: "Andrew R. Reiter" To: Matt Dillon Cc: David Xu , freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance In-Reply-To: <200104101827.f3AIR3H89467@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > FreeBSD implements a very sophisticated VM balancing algorithm. Nobody's > complaining about it so I don't think we need to really change it. Most > of the other UNIXes, including Linux, are actually playing catch-up to > FreeBSD's VM design. > I remember hearing/viewing a zero-copy networking patch for 4.2... Anyone else seen this? If it's already part of the tree, ignore me :-) Andrew *-------------................................................. | Andrew R. Reiter | arr@fledge.watson.org | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 11:37:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 33A8037B423; Tue, 10 Apr 2001 11:37:37 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3AIbbM01608; Tue, 10 Apr 2001 11:37:37 -0700 (PDT) Date: Tue, 10 Apr 2001 11:37:37 -0700 From: Alfred Perlstein To: Bill Paul Cc: hackers@FreeBSD.ORG Subject: Re: sendfile() vs. gigabit ethernet Message-ID: <20010410113736.U15938@fw.wintelcom.net> References: <20010410180514.E229D37B422@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010410180514.E229D37B422@hub.freebsd.org>; from wpaul@FreeBSD.ORG on Tue, Apr 10, 2001 at 11:05:14AM -0700 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Bill Paul [010410 11:05] wrote: > People are constantly asking me about the performance of gigabit ethernet > cards with FreeBSD. I'm constantly wishing they would all go to hell -- > directly to hell, without passing "GO" or collecting $200 -- but their > persistence has led me to ask a few questions of my own. One thing everyone > notices right away is that some of FreeBSD's defaults aren't terribly > optimal for gigabit ethernet, the main one being socket buffer sizes. > At least as far as TCP is concerned, you can do one of two things: > > - Change your application to call setsockopt() and increase the SO_SNDBUF > and SO_RCVBUF values. > - Use sysctl to change the net.inet.tcp.sendspace and net.inet.tcp.recvspace > values. > > The former option affectly only a given application, while the latter > affects the entire system. Most people will bump the sendspace and > recvspace variables since it's easier than modifying their application. > Changing the default from 16K to 64K usually has a drastic effect on > performance with something like ttcp, which is what I typically use > for testing. You can also use the -B flag to ttcp to have it increase > the SNDBUF/RCVBUF values just for itself and achieve the same effect. > > But then what usually happens is people will attempt to perform a file > transfer test using, of all things. FTP, and suddenly they notice that > performance doesn't really improve all that much. I could never understand > just why this was so, until I realized that /usr/libexec/ftpd in FreeBSD > now uses sendfile(). The ttcp utility on the other hand uses write(2) > (as does netperf for that matter). > > So my question is: has anyone done any tests with sendfile() over a > high speed network link and tried to vary the sendspace/recvspace > defaults to improve performance? If so, does it make any difference? > My feeling is that it should, but from what I can tell, sendfile() > only passes data to sosend() in page-sized chunks, and this is somehow > negating the effect of increasing the socket buffer size. Am I right, > or am I just missing something obvious, as usual? Have you considered that the client side doesn't use "receivefile" and therefore is probably an order of magnitude slower? What you might want to try is this ftp> get remote_large_file /dev/null As far as the tcp send/recv space stuff, I agree that the default is kind of low. It's really about time we offered some tunables based on system configuration, for example: depending on ram available: scale: maxusers, nmbclusters turn on: vfs.vmiodirenable when traversing the tcb hashes, detect long chain runs and possibly raise spl/aquire a lock to realloc them to a larger size. I'm sure there's numerous other ssytem things to tune (amount of sysv ipc primatives available) based on the amount of ram. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Represent yourself, show up at BABUG http://www.babug.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 13: 2:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gandalf.vi.bravenet.com (gandalf.bravenet.com [139.142.105.50]) by hub.freebsd.org (Postfix) with SMTP id B290537B424 for ; Tue, 10 Apr 2001 13:02:24 -0700 (PDT) (envelope-from dphoenix@bravenet.com) Received: (qmail 26078 invoked by uid 1000); 10 Apr 2001 20:02:17 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 10 Apr 2001 20:02:17 -0000 Date: Tue, 10 Apr 2001 13:02:17 -0700 (PDT) From: Dan Phoenix To: freebsd-hackers@freebsd.org Subject: lockf in apache Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG show alot of that in top occasioanally....think that could be from nfs timeouts or just waiting on mysql connections to come back? what are they generally from? -- Dan +------------------------------------------------------+ | BRAVENET WEB SERVICES | | dan@bravenet.com | | make installworld | | ln -s /var/qmail/bin/sendmail /usr/sbin/sendmail | | ln -s /var/qmail/bin/newaliases /usr/sbin/newaliases | +______________________________________________________+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 13:12:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 99AFB37B422 for ; Tue, 10 Apr 2001 13:12:54 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3AKCsV04334; Tue, 10 Apr 2001 13:12:54 -0700 (PDT) Date: Tue, 10 Apr 2001 13:12:54 -0700 From: Alfred Perlstein To: Dan Phoenix Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: lockf in apache Message-ID: <20010410131254.V15938@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from dphoenix@bravenet.com on Tue, Apr 10, 2001 at 01:02:17PM -0700 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Dan Phoenix [010410 13:02] wrote: > > > show alot of that in top > occasioanally....think that could be from nfs timeouts > or just waiting on mysql connections to come back? > > what are they generally from? They're using a lockfile around the select() call on the accept'ing socket. Basically, when apache is listening on multiple IPs/ports it needs to select() on several filedescriptors. The problem (under FreeBSD at least) is that whenever you have some process select()'ing on a descriptor and another process wants to do the same you get a "select collision", a collision requires that all processes waiting on the same select channel wake up then reassert thier desire to select. So... if you have 500 apache processes select()'ing and one wakes up to service a request, finished serving, then goes to select again, all the rest (499) have to wake up and reaffirm thier desire to select(). This doesn't scale very well at all. What apache does to fix this, is only allow one process to select() at any given time by keeping a lockf lock on a file while waiting in select(). When select returns it releases the lock and this allows another process to enter the select() call. It's still not as efficient because (under FreeBSD) I think this still can wakeup each process blocked on the lock, but it's still an order of magnitude better than having select() collisions. If you want to get it the most optimal, try to not specify individual IPs for apache to bind to. If you can tell apache to bind to only port 80 on "*" (all IPs) you'll get much better performance because then apache no longer needs to select, it only needs to accept() on a single socket which is the most optimal thing to do. You'll know if you've got the single select working if you see the majority of the apache processes in "accept" rather than "lockf". You might also want to check out using accept filters to get even more performance out of apache, see the accf_http manpage and check the apache docs for the compile time stuff you need to do to enable this. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 14: 6:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.tgd.net (rand.tgd.net [64.81.67.117]) by hub.freebsd.org (Postfix) with SMTP id C02C437B43E for ; Tue, 10 Apr 2001 14:06:48 -0700 (PDT) (envelope-from sean@mailhost.tgd.net) Received: (qmail 30060 invoked by uid 1001); 10 Apr 2001 21:06:44 -0000 Date: Tue, 10 Apr 2001 14:06:43 -0700 From: Sean Chittenden To: Robert Watson Cc: r.hyunseog@ieee.org, hackers@freebsd.org Subject: Re: Interesting article. Message-ID: <20010410140643.A29905@rand.tgd.net> References: <3AD2FF23.239CD9DF@moonworld.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline In-Reply-To: ; from "rwatson@freebsd.org" on Tue, Apr 10, 2001 at = 10:54:16AM X-PGP-Key: 0x1EDDFAAD X-PGP-Fingerprint: C665 A17F 9A56 286C 5CFB 1DEA 9F4F 5CEF 1EDD FAAD X-Web-Homepage: http://sean.chittenden.org/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I know right now that Theo Schlossnagle (from mod_backhand fame), is working on a bi-directional accept filter for keep alives that will allow Apache to pass the connection back to the kernel so that the apache child can serve a different request. scenario: 1) request comes in 2) hits the parent apache process, which holds the connection until there i= s data available 3) passes the connection to an apache child 4) the apache child noticies that the client sent a request with keep alives 5) child serves the request 6) child passes the connection back to the parrent It's working right now on linux, but I think there's a small bug in passing a file descriptor over a pipe. FWIW, I'll let you know if I hear any more regarding this apache patch. -sc On Tue, Apr 10, 2001 at 10:54:16AM -0400, Robert Watson wrote: > One of the interesting pieces of performance work in FreeBSD that has come > out of Yahoo! is the introduction of Accept Filters, which allow > applications to push some customized behavior into the kernel using a > relatively clean interface. It would be interesting to compare the > before/after Accept Filter cases with the before/after IIS kernel > introduction cases. Given the degree of "stuff" pushed into the kernel > under IIS, you might continue to expect a similar or higher level of > performance under Windows 2000, especially with their reengineered IP > stack under Windows 2000.=20 >=20 > Robert N M Watson FreeBSD Core Team, TrustedBSD Project > robert@fledge.watson.org NAI Labs, Safeport Network Services --=20 Sean Chittenden --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: Sean Chittenden iEYEARECAAYFAjrTdeMACgkQn09c7x7d+q3fgwCgmrjddjO7XNTWux3s0NP3fY/F tUsAoN+T4Sl9ETR3FXb3Vu94ql4B4iD+ =aj/N -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 14:56: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from netbank.com.br (garrincha.netbank.com.br [200.203.199.88]) by hub.freebsd.org (Postfix) with ESMTP id 1CED737B443 for ; Tue, 10 Apr 2001 14:55:58 -0700 (PDT) (envelope-from riel@conectiva.com.br) Received: from surriel.ddts.net (3-019.cwb-adsl.brasiltelecom.net.br [200.193.162.19]) by netbank.com.br (Postfix) with ESMTP id 2C0724681D; Tue, 10 Apr 2001 18:56:12 -0300 (BRST) Received: from localhost (fcgiuo@localhost [127.0.0.1]) by surriel.ddts.net (8.11.2/8.11.2) with ESMTP id f3ALkef29990; Tue, 10 Apr 2001 18:46:41 -0300 Date: Tue, 10 Apr 2001 18:46:40 -0300 (BRST) From: Rik van Riel X-Sender: riel@imladris.rielhome.conectiva To: Matt Dillon Cc: David Xu , freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance In-Reply-To: <200104101827.f3AIR3H89467@earth.backplane.com> Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 10 Apr 2001, Matt Dillon wrote: > :I heard NetBSD has implemented a FreeBSD like VM, it also implemented > :a VM balance in recent verion of NetBSD. some parameters like TEXT, > :DATA and anonymous memory space can be tuned. is there anyone doing > :such work on FreeBSD or has FreeBSD already implemented it? > > FreeBSD implements a very sophisticated VM balancing algorithm. Nobody's > complaining about it so I don't think we need to really change it. Most > of the other UNIXes, including Linux, are actually playing catch-up to > FreeBSD's VM design. In the balancing part, definately. FreeBSD seems to be the only system that has the balancing right. I'm planning on integrating some of the balancing tactics into Linux for the 2.5 kernel, but I'm not sure how to integrate the inode and dentry cache into the balancing scheme ... I'm curious about the other things though ... FreeBSD still seems to have the early 90's abstraction layer from Mach and the vnode cache doesn't seem to grow and shrink dynamically (which can be a big win for systems with lots of metadata activity). So while it's true that FreeBSD's VM balancing seems to be the best one out there, I'm not quite sure about the rest of the VM... regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 15: 1:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gandalf.vi.bravenet.com (gandalf.bravenet.com [139.142.105.50]) by hub.freebsd.org (Postfix) with SMTP id 53C8737B42C for ; Tue, 10 Apr 2001 15:01:06 -0700 (PDT) (envelope-from dphoenix@bravenet.com) Received: (qmail 6420 invoked by uid 1000); 10 Apr 2001 22:01:05 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 10 Apr 2001 22:01:05 -0000 Date: Tue, 10 Apr 2001 15:01:05 -0700 (PDT) From: Dan Phoenix To: Alfred Perlstein Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: lockf in apache In-Reply-To: <20010410131254.V15938@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok let's take this for example Listen 172.16.0.26:80 Listen 172.16.6.2:80 NameVirtualHost 172.16.0.26:80 NameVirtualHost 172.16.6.2:80 .6.2 is real ip for load balancer. .0.x is for internal use so let;s rewrite. Bind * Port 80 NameVirtualHost 172.16.0.26 NameVirtualHost 172.16.6.2 this the idea? not even sure why .0.26 etc was setup tha tis just for internal testing but a good thing to have...maybe a NameVirtual * VirtualHost * not sure if i can get away with that....i will play with it for abit.. let me know if you already know off hand. reason we even have namevirtualhost is because we have alot of virtual hosts setup and is required in that case as they all use same ip address. thx. Dan On Tue, 10 Apr 2001, Alfred Perlstein wrote: > Date: Tue, 10 Apr 2001 13:12:54 -0700 > From: Alfred Perlstein > To: Dan Phoenix > Cc: freebsd-hackers@FreeBSD.ORG > Subject: Re: lockf in apache > > * Dan Phoenix [010410 13:02] wrote: > > > > > > show alot of that in top > > occasioanally....think that could be from nfs timeouts > > or just waiting on mysql connections to come back? > > > > what are they generally from? > > They're using a lockfile around the select() call on the accept'ing > socket. > > Basically, when apache is listening on multiple IPs/ports it needs > to select() on several filedescriptors. The problem (under FreeBSD > at least) is that whenever you have some process select()'ing on > a descriptor and another process wants to do the same you get a > "select collision", a collision requires that all processes waiting > on the same select channel wake up then reassert thier desire to > select. So... if you have 500 apache processes select()'ing and > one wakes up to service a request, finished serving, then goes to > select again, all the rest (499) have to wake up and reaffirm thier > desire to select(). > > This doesn't scale very well at all. > > What apache does to fix this, is only allow one process to select() > at any given time by keeping a lockf lock on a file while waiting > in select(). When select returns it releases the lock and this > allows another process to enter the select() call. > > It's still not as efficient because (under FreeBSD) I think this > still can wakeup each process blocked on the lock, but it's still > an order of magnitude better than having select() collisions. > > If you want to get it the most optimal, try to not specify individual > IPs for apache to bind to. If you can tell apache to bind to only > port 80 on "*" (all IPs) you'll get much better performance because > then apache no longer needs to select, it only needs to accept() > on a single socket which is the most optimal thing to do. > > You'll know if you've got the single select working if you see the > majority of the apache processes in "accept" rather than "lockf". > > You might also want to check out using accept filters to get even > more performance out of apache, see the accf_http manpage and check > the apache docs for the compile time stuff you need to do to enable > this. > > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 15: 4:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 750C037B422 for ; Tue, 10 Apr 2001 15:04:16 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3AM4GY07890; Tue, 10 Apr 2001 15:04:16 -0700 (PDT) Date: Tue, 10 Apr 2001 15:04:16 -0700 From: Alfred Perlstein To: Dan Phoenix Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: lockf in apache Message-ID: <20010410150416.E15938@fw.wintelcom.net> References: <20010410131254.V15938@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from dphoenix@bravenet.com on Tue, Apr 10, 2001 at 03:01:05PM -0700 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At a glance the following config should work. If apache is not in 'accept' then you've done something wrong. * Dan Phoenix [010410 15:01] wrote: > > > Ok let's take this for example > > Listen 172.16.0.26:80 > Listen 172.16.6.2:80 > > NameVirtualHost 172.16.0.26:80 > NameVirtualHost 172.16.6.2:80 > > > > .6.2 is real ip for load balancer. > .0.x is for internal use > > so let;s rewrite. > > Bind * > Port 80 > > NameVirtualHost 172.16.0.26 > NameVirtualHost 172.16.6.2 > > > > > this the idea? > not even sure why .0.26 etc was setup tha tis just for internal testing > but a good thing to have...maybe a > NameVirtual * > VirtualHost * > > not sure if i can get away with that....i will play with it for abit.. > let me know if you already know off hand. > reason we even have namevirtualhost is because we have alot of > virtual hosts setup and is required in that case as they all use same ip > address. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 15:37:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from england.inhouse (gw.estinc.com [216.216.240.51]) by hub.freebsd.org (Postfix) with ESMTP id 73FF237B424 for ; Tue, 10 Apr 2001 15:37:22 -0700 (PDT) (envelope-from eric@estinc.com) Received: from localhost (IDENT:eric@localhost.localdomain [127.0.0.1]) by england.inhouse (8.9.3/8.9.3) with ESMTP id PAA09866; Tue, 10 Apr 2001 15:39:06 -0700 Date: Tue, 10 Apr 2001 15:39:06 -0700 (MST) From: Eric Lee Green X-Sender: eric@england.inhouse To: r.hyunseog@ieee.org Cc: hackers@FreeBSD.ORG Subject: Re: Interesting article. In-Reply-To: <3AD2FF23.239CD9DF@moonworld.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 10 Apr 2001, HyunSeog Ryu wrote: > . Migrating Microsoft=AE Hotmail=AE from FreeBSD to Microsoft Windows=AE = 2000 > Technical Case Study =20 > http://www.microsoft.com/technet/migration/hotmail/default.asp=20 They forgot to document reason #0 for migration to Windows 2000: Because running FreeBSD made people laugh at their salesmen whenever their salesmen suggested migrating from Unix to Windows 2000. "If Windows 2000 is so good compared to Unix, why is Hotmail still running FreeBSD?". --=20 Eric Lee Green eric@estinc.com Software Engineer "The BRU Guys" Enhanced Software Technologies, Inc. http://www.estinc.com/ (602) 470-1115 voice (602) 470-1116 fax To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 16:12:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id BE83D37B42C; Tue, 10 Apr 2001 16:12:18 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3ANCGM09936; Tue, 10 Apr 2001 16:12:16 -0700 (PDT) Date: Tue, 10 Apr 2001 16:12:16 -0700 From: Alfred Perlstein To: Eric Lee Green Cc: r.hyunseog@ieee.org, hackers@FreeBSD.ORG, advocasy@FreeBSD.ORG Subject: Re: Interesting article. Message-ID: <20010410161216.G15938@fw.wintelcom.net> References: <3AD2FF23.239CD9DF@moonworld.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: ; from eric@estinc.com on Tue, Apr 10, 2001 at 03:39:06PM -0700 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Eric Lee Green [010410 15:38] wrote: > On Tue, 10 Apr 2001, HyunSeog Ryu wrote: > > . Migrating Microsoft® Hotmail® from FreeBSD to Microsoft Windows® 2000 > > Technical Case Study > > http://www.microsoft.com/technet/migration/hotmail/default.asp > > They forgot to document reason #0 for migration to Windows 2000: Because > running FreeBSD made people laugh at their salesmen whenever their > salesmen suggested migrating from Unix to Windows 2000. "If Windows 2000 > is so good compared to Unix, why is Hotmail still running FreeBSD?". The Migration took them over 2 years! (from http://www.microsoft.com/technet/migration/hotmail/default.asp): Microsoft Hotmail web-based e-mail service is one of the most widely adopted free e-mail services available on the Internet. Acquired by Microsoft in 1997, with an installed base of 9 million users,... The Migration wasn't completed until after USENIX 2000. If they had any intention of being fair, they would have also mentioned that: 1) The migration took over a year (most likely two years) because they needed to constantly retune Windows to perform as well as FreeBSD even though they state: (from http://www.microsoft.com/technet/migration/hotmail/hotplan.asp) " The reasons for converting to Windows 2000 were: 1.Performance (and therefore cost). The cgi "one-process-per-socket" model, under FreeBSD, is very inefficient. Per machine throughput can be dramatically improved by moving to a multi-threaded application model. This results in one of the following conditions: o) A fewer number of servers required to support the site o) Support for a greater number of users by using the servers already deployed at the site " I'm sure if they added the cost of the redesign and hacks they had to do (cost of an entire software/ops team for about a year) it would not be cost effective. Nevermind that fact that it would have been impossible without source licenses from Microsoft for a bunch of tools. Something nearly impossible to attain without great cost if you're not actually Microsoft. :) 2) There was nothing forcing them to use CGI under FreeBSD, they could have migrated to Fast-CGI or a threading model under FreeBSD. They choose to go nuts and over-spend on this silly migration which was nothing more than a PR move. 3) Effectively once Mircosoft took over Hotmail, all developemnt efforts on the FreeBSD side were halted, this obviously made the point mentioned in #2 impossible. In fact there were some efforts to make FreeBSD outperform the new NT hacks, but they were not allowed to be deployed. Basically a _MASSIVE_ effort was undertaken at great expense to replace FreeBSD. Something that would most likely not be possible by your average web site without much handholding from Microsoft as well as over two years of work to undertake such a migration. With Microsoft holding your hand, they've still got a spare hand for reaching into your wallet. :) Actually, if you read the footnote F2: " F2 - There obviously are multi-tasking/multi-process solutions that Hotmail could have leveraged under FreeBSD. However, they would require making application modifications and rework to implement. So, this was an optimum opportunity to examine other options and platforms. " Trully this was a cost effective and justfied reason to switch out the underlying OS instead of doing a couple of hacks to the already deployed applications. Of course I'm being sarcastic. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 16:21:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id CAF7137B424 for ; Tue, 10 Apr 2001 16:21:41 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3ANLP994366; Tue, 10 Apr 2001 16:21:25 -0700 (PDT) (envelope-from dillon) Date: Tue, 10 Apr 2001 16:21:25 -0700 (PDT) From: Matt Dillon Message-Id: <200104102321.f3ANLP994366@earth.backplane.com> To: Rik van Riel Cc: David Xu , freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :In the balancing part, definately. FreeBSD seems to be the only :system that has the balancing right. I'm planning on integrating :some of the balancing tactics into Linux for the 2.5 kernel, but :I'm not sure how to integrate the inode and dentry cache into the :balancing scheme ... :I'm curious about the other things though ... FreeBSD still seems :to have the early 90's abstraction layer from Mach and the vnode :cache doesn't seem to grow and shrink dynamically (which can be a :big win for systems with lots of metadata activity). : :So while it's true that FreeBSD's VM balancing seems to be the :best one out there, I'm not quite sure about the rest of the VM... : :regards, : :Rik Well, the approach we take is that of a two-layered cache. The vnode, dentry (namei for FreeBSD), and inode caches in FreeBSD are essentially throw-away caches of data represented in an internal form. The VM PAGE cache 'backs' these caches loosely by caching the physical on-disk representation of inodes, and directory entries (see note 1 at bottom). This means that even though we limit the number of the namei and inode structures we keep around in the kernel, the data required to reconstitute those structures is 'likely' to still be in the VM PAGE cache, allowing us to pretty much throw away those structures on a whim. The only cost is that we have to go through a filesystem op (possibly not requiring I/O) to reconstitute the internal structure. For example, take the namei cache. The namei cache allows the kernel to bypass big pieces of the filesystem when doing path name lookups. If a path is not in the namei cache the filesystem has to do a directory lookup. But a directory lookup could very well access pages in the VM PAGE cache and thus still not actually result in a disk I/O. The inode cache works the same way ... inodes can be thrown away at any time and most of the time they can be reconstituted from the VM PAGE cache without an I/O. The vnode cache works slightly differently. VNodes that are not in active use can be thrown away and reconstituted at a later time from either the inode cache or the VM PAGE cache (or if not then require a disk I/O to get at the stat information). There is a caviat for the vnode cache, however. VNodes are tightly integrated with VM Objects which in turn help place hold VM pages in the VM PAGE cache. Thus when you throw away an inactive vnode you also have to throw away any cached VM PAGES representing the cached file or directory data represented by that vnode. Nearly all installations of FreeBSD run out of physical memory long before they run out of vnodes, so this side effect is almost never an issue. On some extremely rare occassions it is possible that the system will have plenty of free memory but hit its vnode cache limit and start recycling vnodes, causing it to recycle cache pages even when there is plenty of free memory available. But this is very rare. The key point to all of this is that we put most of our marbles in the VM PAGE cache. The namei and inode caches are there simply for convenience so we don't have to 'lock' big portions of the underlying VM PAGE cache. The VM PAGE cache is pretty much an independant entity. It does not know or care *what* is being cached, it only cares how often the data is being accessed and whether it is clean or dirty. It treats all the data nearly the same. note (1): Physical directory blocks have historically been cached in the buffer cache, using kernel MALLOC space, not in the VM PAGE cache. buffer-cache based MALLOC space is severely limited (only a few megabytes) compared to what the VM PAGE cache can offer. In FreeBSD a 'sysctl -w vfs.vmiodirenable=1' will cause physical directory blocks to be cached in the VM PAGE Cache, just like files are cached. This is not the default but it will be soon, and many people already turn this sysctl on. - I should also say that there is a *forth* cache not yet mentioned which actually has a huge effect on the VM PAGE cache. This fourth cache relates to pages *actively* mapped into user space. A page mapped into user space is wired (cannot be ripped out of the VM PAGE cache) and also has various other pmap-related tracking structures (which you are familiar with, Rik, so I won't expound on that too much). If the VM PAGE cache wants to get rid of an idle page that is still mapped to a user process, it has to unwire it first which means it has to get rid of the user mappings - a pmap*() call from vm/vm_pageout.c and vm/vm_page.c accomplishes this. This fourth cache (the active user mappings of pages) is also a throw away cache, though one with the side effect of making VM PAGE cache pages available for loading into user process's memory maps. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 16:46: 1 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gandalf.vi.bravenet.com (gandalf.bravenet.com [139.142.105.50]) by hub.freebsd.org (Postfix) with SMTP id ED5AB37B422 for ; Tue, 10 Apr 2001 16:45:54 -0700 (PDT) (envelope-from dphoenix@bravenet.com) Received: (qmail 3902 invoked by uid 1000); 10 Apr 2001 23:45:54 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 10 Apr 2001 23:45:54 -0000 Date: Tue, 10 Apr 2001 16:45:54 -0700 (PDT) From: Dan Phoenix To: Alfred Perlstein Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: lockf in apache In-Reply-To: <20010410150416.E15938@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG thanks alot for your help alfred much appreciated. you were right all lockf's turned to accepts right after i made that change.....thanks again. On Tue, 10 Apr 2001, Alfred Perlstein wrote: > Date: Tue, 10 Apr 2001 15:04:16 -0700 > From: Alfred Perlstein > To: Dan Phoenix > Cc: freebsd-hackers@FreeBSD.ORG > Subject: Re: lockf in apache > > At a glance the following config should work. If apache is not in > 'accept' then you've done something wrong. > > > * Dan Phoenix [010410 15:01] wrote: > > > > > > Ok let's take this for example > > > > Listen 172.16.0.26:80 > > Listen 172.16.6.2:80 > > > > NameVirtualHost 172.16.0.26:80 > > NameVirtualHost 172.16.6.2:80 > > > > > > > > .6.2 is real ip for load balancer. > > .0.x is for internal use > > > > so let;s rewrite. > > > > Bind * > > Port 80 > > > > NameVirtualHost 172.16.0.26 > > NameVirtualHost 172.16.6.2 > > > > > > > > > > this the idea? > > not even sure why .0.26 etc was setup tha tis just for internal testing > > but a good thing to have...maybe a > > NameVirtual * > > VirtualHost * > > > > not sure if i can get away with that....i will play with it for abit.. > > let me know if you already know off hand. > > reason we even have namevirtualhost is because we have alot of > > virtual hosts setup and is required in that case as they all use same ip > > address. > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 18:44: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from netbank.com.br (garrincha.netbank.com.br [200.203.199.88]) by hub.freebsd.org (Postfix) with ESMTP id 0CA5F37B422 for ; Tue, 10 Apr 2001 18:43:57 -0700 (PDT) (envelope-from riel@conectiva.com.br) Received: from surriel.ddts.net (1-152.cwb-adsl.brasiltelecom.net.br [200.193.160.152]) by netbank.com.br (Postfix) with ESMTP id 2FCB546819; Tue, 10 Apr 2001 22:43:58 -0300 (BRST) Received: from localhost (fauxtc@localhost [127.0.0.1]) by surriel.ddts.net (8.11.2/8.11.2) with ESMTP id f3B1YJf03218; Tue, 10 Apr 2001 22:34:23 -0300 Date: Tue, 10 Apr 2001 22:34:19 -0300 (BRST) From: Rik van Riel X-Sender: riel@imladris.rielhome.conectiva To: Matt Dillon Cc: David Xu , freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance In-Reply-To: <200104102321.f3ANLP994366@earth.backplane.com> Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 10 Apr 2001, Matt Dillon wrote: > :I'm curious about the other things though ... FreeBSD still seems > :to have the early 90's abstraction layer from Mach and the vnode > :cache doesn't seem to grow and shrink dynamically (which can be a > :big win for systems with lots of metadata activity). > Well, the approach we take is that of a two-layered cache. > The vnode, dentry (namei for FreeBSD), and inode caches > in FreeBSD are essentially throw-away caches of data > represented in an internal form. The VM PAGE cache 'backs' > these caches loosely by caching the physical on-disk representation > of inodes, and directory entries (see note 1 at bottom). > > This means that even though we limit the number of the namei > and inode structures we keep around in the kernel, the data > required to reconstitute those structures is 'likely' to > still be in the VM PAGE cache, allowing us to pretty much > throw away those structures on a whim. The only cost is that > we have to go through a filesystem op (possibly not requiring I/O) > to reconstitute the internal structure. Which is ok if there isn't too much activity with these data structures, but I'm not sure if it works when you have a lot of metadata activity (though I'm not sure in what kind of workload you'd see this). Also, if you have a lot of metadata activity, you'll essentially double the memory requirements, since you'll have the stuff cached in both the internal structures and in the VM PAGE cache. I'm not sure how much of a hit this would be, though, if the internal structures are limited to a small enough size... regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 19:44:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id C854E37B422 for ; Tue, 10 Apr 2001 19:44:24 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3B2iHk97869; Tue, 10 Apr 2001 19:44:17 -0700 (PDT) (envelope-from dillon) Date: Tue, 10 Apr 2001 19:44:17 -0700 (PDT) From: Matt Dillon Message-Id: <200104110244.f3B2iHk97869@earth.backplane.com> To: Rik van Riel Cc: David Xu , freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It's randomness that will kill performance. You know the old saying about caches: They only work if you get cache hits, otherwise they only slow things down. -Matt :Which is ok if there isn't too much activity with these data :structures, but I'm not sure if it works when you have a lot :of metadata activity (though I'm not sure in what kind of :workload you'd see this). : :Also, if you have a lot of metadata activity, you'll essentially :double the memory requirements, since you'll have the stuff cached :in both the internal structures and in the VM PAGE cache. I'm not :sure how much of a hit this would be, though, if the internal :structures are limited to a small enough size... : :regards, : :Rik To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 20:23: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from orvieto.eecs.harvard.edu (orvieto.eecs.harvard.edu [140.247.60.201]) by hub.freebsd.org (Postfix) with ESMTP id BACB037B422; Tue, 10 Apr 2001 20:22:56 -0700 (PDT) (envelope-from stein@eecs.harvard.edu) Received: from localhost (stein@localhost) by orvieto.eecs.harvard.edu (8.9.3/8.9.3) with ESMTP id XAA15599; Tue, 10 Apr 2001 23:29:24 -0400 (EDT) (envelope-from stein@eecs.harvard.edu) X-Authentication-Warning: orvieto.eecs.harvard.edu: stein owned process doing -bs Date: Tue, 10 Apr 2001 23:29:24 -0400 (EDT) From: Christopher Stein To: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Vino Project Subject: Write-ahead file system (WAFS) for FreeBSD Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Write-Ahead File System (WAFS) v1.0 Release Notice. The WAFS source code is now available for download at http://www.eecs.harvard.edu/~stein/wafs/ WAFS is a simple file system designed to act as a logging service for kernel subsystems. Reads and writes are keyed by log-sequence number (LSN). All writes to WAFS are sequential. Kernel subsystems can use this LSN service to enforce write-ahead logging and guarantee consistency. Potential clients of the WAFS include, but are not limited to; a journaling file system, a database system, and a block hash logging service. The list of potential WAFS clients is bounded by the human imagination. The WAFS is built within FreeBSD 4.1-RELEASE. Chris Stein To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 21:53:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from alpha.dtix.com (alpha.dtix.com [198.62.174.1]) by hub.freebsd.org (Postfix) with ESMTP id CD91637B422 for ; Tue, 10 Apr 2001 21:53:47 -0700 (PDT) (envelope-from pradip@dtix.com) Received: from dtix.com (gopal.dtix.com [203.200.166.66]) by alpha.dtix.com (8.9.3/8.8.7) with ESMTP id BAA11616 for ; Wed, 11 Apr 2001 01:19:51 -0400 Message-ID: <3AD3E3C8.B8B5A00@dtix.com> Date: Wed, 11 Apr 2001 10:25:36 +0530 From: pradip biswas Organization: Dynamic Digital Technology X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org Subject: problem in attaching a PCI driver Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I have gone through the tutorial composed be you on FreeBSD.org page. I am developing a loadable module on FreeBSD which will act a network pci card driver. The problem with the module is that, the probe/attach routines are not getting called. I have filled a driver_t, devclass_t and used the DRIVER_MODULE macro to register the probe/attach/detach routines. There is no other macro used. What changes should be made to make it work? Should there be any other macro in the code or any prior change in any system file? Thanks. --pradip To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 10 22:14:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from filk.iinet.net.au (syncopation-dns.iinet.net.au [203.59.24.29]) by hub.freebsd.org (Postfix) with SMTP id 193D237B423 for ; Tue, 10 Apr 2001 22:14:56 -0700 (PDT) (envelope-from julian@elischer.org) Received: (qmail 3287 invoked by uid 666); 11 Apr 2001 05:17:22 -0000 Received: from i188-081.nv.iinet.net.au (HELO elischer.org) (203.59.188.81) by mail.m.iinet.net.au with SMTP; 11 Apr 2001 05:17:22 -0000 Message-ID: <3AD3E834.AFB6C5BA@elischer.org> Date: Tue, 10 Apr 2001 22:14:28 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Rik van Riel Cc: Matt Dillon , David Xu , freebsd-hackers@FreeBSD.ORG, mckusick@mckusick.com Subject: Re: vm balance References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Rik van Riel wrote: > > I'm curious about the other things though ... FreeBSD still seems > to have the early 90's abstraction layer from Mach and the vnode > cache doesn't seem to grow and shrink dynamically (which can be a > big win for systems with lots of metadata activity). > > So while it's true that FreeBSD's VM balancing seems to be the > best one out there, I'm not quite sure about the rest of the VM... > Many years ago Kirk was talking about merging the vm objects and the vnodes.. (they tend to come in pairs anyhow) I still think it might be an idea worth investigating further. kirk? -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 11 0: 0:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 8FC7037B42C for ; Wed, 11 Apr 2001 00:00:48 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f3B70fV20559; Wed, 11 Apr 2001 01:00:43 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200104110700.f3B70fV20559@harmony.village.org> To: "Brian W. Buchanan" Subject: Re: PCMCIA-PCI bridge cards Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Sat, 07 Apr 2001 18:11:00 PDT." References: Date: Wed, 11 Apr 2001 00:59:26 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message "Brian W. Buchanan" writes: : Do PCI PCMCIA adapters work in 4.3? No. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 11 0:22:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 22B8237B422 for ; Wed, 11 Apr 2001 00:22:40 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f3B7MVV20796; Wed, 11 Apr 2001 01:22:31 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200104110722.f3B7MVV20796@harmony.village.org> Subject: Re: PCMCIA-PCI bridge cards Cc: "Brian W. Buchanan" , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Wed, 11 Apr 2001 00:59:26 MDT." <200104110700.f3B70fV20559@harmony.village.org> References: <200104110700.f3B70fV20559@harmony.village.org> Date: Wed, 11 Apr 2001 01:21:16 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200104110700.f3B70fV20559@harmony.village.org> Warner Losh writes: : In message "Brian W. Buchanan" writes: : : Do PCI PCMCIA adapters work in 4.3? : : No. I should amplify a little here. The pci cards that plug into a desktop route interrupts over the pci bus. This routing reqires programming the bridge chip in a certain way. OLDCARD doesn't know how to do this. The same pci cardbus bridges in laptops are subtlely different. They include a "back door" to the ISA bus of some flavor. With this backdoor, we can do what we've always done and route via ISA interrupt back door and not have to change anything to use these chips in "legacy" mode. There are some things that might change this in time for 4.4. Time will tell, but I don't want to say too much about this just yet. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 11 7: 1:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.30.2]) by hub.freebsd.org (Postfix) with ESMTP id EC0A937B423 for ; Wed, 11 Apr 2001 07:01:24 -0700 (PDT) (envelope-from kuku@gilberto.physik.rwth-aachen.de) Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.11.1/8.9.3) id f3BE1OT19399 for hackers@freebsd.org; Wed, 11 Apr 2001 16:01:24 +0200 (CEST) (envelope-from kuku) Date: Wed, 11 Apr 2001 16:01:24 +0200 (CEST) From: Christoph Kukulies Message-Id: <200104111401.f3BE1OT19399@gilberto.physik.rwth-aachen.de> To: hackers@freebsd.org Subject: OUTPORT / outb instructions - where defined? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm seeking the header file in FreeBSD which corresponds to asm/io.h in Linux. It should contain macros like OUTPORT, INPORT etc. to do direct port io. I want to port a little program (MPMAN) which can upload files to a MP3 player. -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 11 7:10:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rjspc.uk.genrad.com (x149.genrad.co.uk [195.99.3.149]) by hub.freebsd.org (Postfix) with ESMTP id E06A437B422 for ; Wed, 11 Apr 2001 07:10:26 -0700 (PDT) (envelope-from swindellsr@genrad.com) Received: from CDP437 (cdp437.uk.genrad.com [132.223.135.120]) by rjspc.uk.genrad.com (8.9.3/8.6.12) with SMTP id PAA00537; Wed, 11 Apr 2001 15:12:25 +0100 (BST) Date: Wed, 11 Apr 2001 15:12:25 +0100 (BST) Message-Id: <200104111412.PAA00537@rjspc.uk.genrad.com> From: Robert Swindells To: kuku@gilberto.physik.rwth-aachen.de Cc: hackers@freebsd.org In-reply-to: <200104111401.f3BE1OT19399@gilberto.physik.rwth-aachen.de> (message from Christoph Kukulies on Wed, 11 Apr 2001 16:01:24 +0200 (CEST)) Subject: Re: OUTPORT / outb instructions - where defined? Reply-To: rjs@fdy2.demon.co.uk Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >I'm seeking the header file in FreeBSD which corresponds to asm/io.h >in Linux. It should contain macros like OUTPORT, INPORT etc. >to do direct port io. I want to port a little program >(MPMAN) which can upload files to a MP3 player. The arguments to out[bwl] are reversed from Linux though. Robert To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 11 7:15:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.30.2]) by hub.freebsd.org (Postfix) with ESMTP id 7816837B422 for ; Wed, 11 Apr 2001 07:15:17 -0700 (PDT) (envelope-from kuku@gilberto.physik.rwth-aachen.de) Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.11.1/8.9.3) id f3BEEFV19542; Wed, 11 Apr 2001 16:14:15 +0200 (CEST) (envelope-from kuku) Date: Wed, 11 Apr 2001 16:14:15 +0200 From: Christoph Kukulies To: rjs@fdy2.demon.co.uk Cc: kuku@gilberto.physik.rwth-aachen.de, hackers@freebsd.org Subject: Re: OUTPORT / outb instructions - where defined? Message-ID: <20010411161415.A19526@gil.physik.rwth-aachen.de> References: <200104111401.f3BE1OT19399@gilberto.physik.rwth-aachen.de> <200104111412.PAA00537@rjspc.uk.genrad.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200104111412.PAA00537@rjspc.uk.genrad.com>; from swindellsr@genrad.com on Wed, Apr 11, 2001 at 03:12:25PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Apr 11, 2001 at 03:12:25PM +0100, Robert Swindells wrote: > > >I'm seeking the header file in FreeBSD which corresponds to asm/io.h > >in Linux. It should contain macros like OUTPORT, INPORT etc. > >to do direct port io. I want to port a little program > >(MPMAN) which can upload files to a MP3 player. > > > > The arguments to out[bwl] are reversed from Linux though. Thanks. This list is faster than 'grep' :-) > > Robert -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 11 10:16:52 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from synaps.bi.itb.ac.id (synaps.bi.itb.ac.id [167.205.24.99]) by hub.freebsd.org (Postfix) with ESMTP id 5B32D37B422 for ; Wed, 11 Apr 2001 10:16:39 -0700 (PDT) (envelope-from ali@synaps.bi.itb.ac.id) Received: from localhost (ali@localhost) by synaps.bi.itb.ac.id (8.9.3/8.9.3) with ESMTP id XAA64245 for ; Wed, 11 Apr 2001 23:42:21 +0700 (JAVT) (envelope-from ali@synaps.bi.itb.ac.id) Date: Wed, 11 Apr 2001 23:42:21 +0700 (JAVT) From: Muhammad Ali Rizal To: freebsd-hackers@freebsd.org Subject: cannot make build-tools Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi ! I tried to cvsup my FreeBSD 4.0-RELEASE. I did the following steps : 1. cvsup /etc/cvsupfile 2. remove /usr/obj 3. make -DNOPROFILE=true buildworld during the 3rd step everything seemed fine until it appeared message like this : -------------------------------------------------------------- >>> stage 2: build tools -------------------------------------------------------------- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 build-tools cd /usr/src/bin/csh; make build-tools make: don't know how to make gethost.c. Stop *** Error code 2 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 How to solve this problem ? wassalam -ali- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 11 15: 9:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gatekeeper.orem.verio.net (gatekeeper.orem.verio.net [192.41.0.8]) by hub.freebsd.org (Postfix) with ESMTP id 8EEBA37B422 for ; Wed, 11 Apr 2001 15:09:12 -0700 (PDT) (envelope-from fclift@verio.net) Received: from mx.dmz.orem.verio.net (mx.dmz.orem.verio.net [10.1.1.10]) by gatekeeper.orem.verio.net (Postfix) with ESMTP id C0FD53BF174 for ; Wed, 11 Apr 2001 16:09:11 -0600 (MDT) Received: from vespa.dmz.orem.verio.net (vespa.dmz.orem.verio.net [10.1.1.59]) by mx.dmz.orem.verio.net (8.11.1/8.11.1) with ESMTP id f3BM91n10056; Wed, 11 Apr 2001 16:09:02 -0600 (MDT) (envelope-from fclift@verio.net) Date: Wed, 11 Apr 2001 16:39:04 -0600 (MDT) From: Fred Clift X-Sender: fred@vespa.dmz.orem.verio.net To: dannyman Cc: Doug White , freebsd-hackers@FreeBSD.ORG Subject: Re: creating an fdisk partition in an automated way In-Reply-To: <20010406181255.H59108@dell.dannyland.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 6 Apr 2001, dannyman wrote: > On Wed, Apr 04, 2001 at 08:58:12PM -0700, Doug White wrote: > > fdisk -I is your friend. (DANGER: THIS IS DESTRUCTIVE -- READ THE MAN ... > Yeah ... I use it. It seems to do the right thing. Then disklabel doesn't > work. :< ... > disklabel -r -w $disk auto > > Disklabel pukes. I've found a similar case at: > http://groups.google.com/groups?q=%22cannot+find+label%22+%22no+disk+label%22+fdisk&hl=en&lr=&safe=off&rnum=1&seld=972266336&ic=1 Disklabel XXXX auto only works on 'raw' disks. I mean, it wasn't written to work on partitions er slices. This wouldn't be a bug, but more a feature enhancement. I'm sure it could be implemented. Let us all know when you get it fixed :). Fred -- Fred Clift - fclift@verio.net -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 11 16: 7:36 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.122.47]) by hub.freebsd.org (Postfix) with ESMTP id C121237B423 for ; Wed, 11 Apr 2001 16:07:31 -0700 (PDT) (envelope-from dwhite@resnet.uoregon.edu) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.10.1/8.10.1) with ESMTP id f3BN7PI53416; Wed, 11 Apr 2001 16:07:25 -0700 (PDT) Date: Wed, 11 Apr 2001 16:07:25 -0700 (PDT) From: Doug White To: Alfred Perlstein Cc: Dan Phoenix , Subject: Re: lockf in apache In-Reply-To: <20010410131254.V15938@fw.wintelcom.net> Message-ID: X-All-Your-Base: are belong to us MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 10 Apr 2001, Alfred Perlstein wrote: > Basically, when apache is listening on multiple IPs/ports it needs > to select() on several filedescriptors. The problem (under FreeBSD > at least) is that whenever you have some process select()'ing on > a descriptor and another process wants to do the same you get a > "select collision", a collision requires that all processes waiting > on the same select channel wake up then reassert thier desire to > select. So... if you have 500 apache processes select()'ing and > one wakes up to service a request, finished serving, then goes to > select again, all the rest (499) have to wake up and reaffirm thier > desire to select(). We haven't applied wakeup_one() to select() yet? (I think I've argued about this before.) Someone get cracking! :) Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 11 16:19: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 794E337B422 for ; Wed, 11 Apr 2001 16:18:59 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3BNIwT16523; Wed, 11 Apr 2001 16:18:58 -0700 (PDT) Date: Wed, 11 Apr 2001 16:18:58 -0700 From: Alfred Perlstein To: Doug White Cc: Dan Phoenix , freebsd-hackers@FreeBSD.ORG Subject: Re: lockf in apache Message-ID: <20010411161858.T15938@fw.wintelcom.net> References: <20010410131254.V15938@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from dwhite@resnet.uoregon.edu on Wed, Apr 11, 2001 at 04:07:25PM -0700 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Doug White [010411 16:07] wrote: > On Tue, 10 Apr 2001, Alfred Perlstein wrote: > > > Basically, when apache is listening on multiple IPs/ports it needs > > to select() on several filedescriptors. The problem (under FreeBSD > > at least) is that whenever you have some process select()'ing on > > a descriptor and another process wants to do the same you get a > > "select collision", a collision requires that all processes waiting > > on the same select channel wake up then reassert thier desire to > > select. So... if you have 500 apache processes select()'ing and > > one wakes up to service a request, finished serving, then goes to > > select again, all the rest (499) have to wake up and reaffirm thier > > desire to select(). > > We haven't applied wakeup_one() to select() yet? (I think I've argued > about this before.) > > Someone get cracking! :) I'm not sure it's possible without redesigning the way select works. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 11 16:32:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 76F3837B424 for ; Wed, 11 Apr 2001 16:32:39 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f3BNWPG13232; Wed, 11 Apr 2001 16:32:25 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010411161858.T15938@fw.wintelcom.net> Date: Wed, 11 Apr 2001 16:31:56 -0700 (PDT) From: John Baldwin To: Alfred Perlstein Subject: Re: lockf in apache Cc: freebsd-hackers@FreeBSD.org, Dan Phoenix , Doug White Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 11-Apr-01 Alfred Perlstein wrote: > * Doug White [010411 16:07] wrote: >> On Tue, 10 Apr 2001, Alfred Perlstein wrote: >> >> > Basically, when apache is listening on multiple IPs/ports it needs >> > to select() on several filedescriptors. The problem (under FreeBSD >> > at least) is that whenever you have some process select()'ing on >> > a descriptor and another process wants to do the same you get a >> > "select collision", a collision requires that all processes waiting >> > on the same select channel wake up then reassert thier desire to >> > select. So... if you have 500 apache processes select()'ing and >> > one wakes up to service a request, finished serving, then goes to >> > select again, all the rest (499) have to wake up and reaffirm thier >> > desire to select(). >> >> We haven't applied wakeup_one() to select() yet? (I think I've argued >> about this before.) >> >> Someone get cracking! :) > > I'm not sure it's possible without redesigning the way select works. Select does a wakeup_one() if there's not a collision on a fd. If there is a collision, you need to do a full wakeup() since wakeup_one() on &selwait could easily just wake up a process waiting on some other fd and not a process waiting on the fd in question. xref. sys/kern/sys_generic.c, specifically selrecord() and selwakeup(). -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 11 19:50:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ambrisko.com (adsl-216-103-208-74.dsl.snfc21.pacbell.net [216.103.208.74]) by hub.freebsd.org (Postfix) with ESMTP id BFAF937B42C for ; Wed, 11 Apr 2001 19:50:20 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.11.3/8.11.2) id f3C2oGk29529; Wed, 11 Apr 2001 19:50:16 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200104120250.f3C2oGk29529@ambrisko.com> Subject: Re: problem with Aironet driver In-Reply-To: <3AD3303D.7E01528D@tovaris.com> "from Andria Thomas at Apr 10, 2001 12:09:33 pm" To: Andria Thomas Date: Wed, 11 Apr 2001 19:50:16 -0700 (PDT) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Andria Thomas writes: | Recently, we've seen messages like the following spewed to the consoles | of each machine: | | Mar 26 14:25:57 gw /kernel: an0: id mismatch: expected 178, got 224 | Mar 26 14:25:57 gw /kernel: an0: id mismatch: expected 17e, got 178 | | When these messages begin, our network connection grinds to a near-halt | (ping times of 1000-2000ms). The only way we've found to stop the | messages is to disconnect the Aironet connection, and bring the network | interface down and back up again. When it comes back up, everything is | mysteriously back to normal. | | I've tried looking through the source code, but confess to not | understanding what it is that prompts these messages to begin. Any help | | would be greatly appreciated. I've tried poring through mailing list | archives, but no one else seems to have reported a similar problem. Actually a few people have. I had a fix in my sets of patches but it seems that was omited so even though the problem was solved it it still broken. Hopefully we won't miss the fix again. Please try this patch. You will have to apply it by hand to /sys/dev/an/if_an.c since I did an X cut-n-paste. Let me know if it helps. Thanks, Doug A. *************** *** 483,494 **** } else ifp->if_opackets++; ! if (id != sc->an_rdata.an_tx_ring[sc->an_rdata.an_tx_cons]) ! printf("an%d: id mismatch: expected %x, got %x\n", ! sc->an_unit, ! sc->an_rdata.an_tx_ring[sc->an_rdata.an_tx_cons], id); - sc->an_rdata.an_tx_ring[sc->an_rdata.an_tx_cons] = 0; AN_INC(sc->an_rdata.an_tx_cons, AN_TX_RING_CNT); return; --- 484,496 ---- } else ifp->if_opackets++; ! for (i = 0; i < AN_TX_RING_CNT; i++ ) { ! if (id == sc->an_rdata.an_tx_ring[i]) { ! sc->an_rdata.an_tx_ring[i] = 0; ! break; ! } ! } AN_INC(sc->an_rdata.an_tx_cons, AN_TX_RING_CNT); return; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 11 21:23:26 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.fureai.or.jp (mail.fureai.or.jp [203.179.2.251]) by hub.freebsd.org (Postfix) with ESMTP id 7382237B50B; Wed, 11 Apr 2001 21:23:07 -0700 (PDT) (envelope-from natori@mad.scientist.com) Received: from localhost (ppp108.td.fureai.or.jp [210.143.57.108]) by mail.fureai.or.jp (8.9.3/3.7W) with ESMTP id NAA15537; Thu, 12 Apr 2001 13:23:05 +0900 (JST) Message-Id: <200104120423.NAA15537@mail.fureai.or.jp> To: FreeBSD-questions@freebsd.org, FreeBSD-hackers@freebsd.org Subject: nfsd hangs in ``inode'' state X-Mailer: Mew version 1.92.1 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 12 Apr 2001 13:23:01 +0900 From: "S. Natori" Lines: 66 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello All, I am running a FreeBSD-4.2 NFS server with dozens of FreeBSD-4.2 NFS clients on 100BaseTX LAN. Recently I found that when the NFS server receives a lot of requests in a short period (e.g., 2 clients start X with gnome desktop simultaneously), all nfsd server processes hang in inode state. UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 0 440 1 0 2 0 360 132 accept Is ?? 0:00.00 nfsd: master (nfsd) 0 441 440 0 -14 0 352 124 inode D ?? 0:03.49 nfsd: server (nfsd) 0 442 440 0 -14 0 352 124 inode D ?? 0:00.17 nfsd: server (nfsd) 0 443 440 0 -14 0 352 124 inode D ?? 0:00.02 nfsd: server (nfsd) 0 444 440 0 -14 0 352 124 inode D ?? 0:00.01 nfsd: server (nfsd) I cannot kill or restart them. The consoles of the clients print ``NFS server not responding'' and I should restart the server. This occurs about once a week. I tried (1) increasing the number of nfsd processes (4 -> 8, 20) (2) replacing the server HDD (SCSI) with another ATA33 HDD (3) changing mount_nfs options (tried removing tcp, adding soft,dumbtimer) but all failed to solve the problem. Perhaps this problem is the one reported previously in http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=1913802+1916627+/usr/local/www/db/text/2000/freebsd-questions/20001008.freebsd-questions The reporter avoided this problem by switching to NetBSD, but I prefer FreeBSD. Do you have any idea to solve or circumvent this problem? Any suggestions would be appreciated. Many thanks in advance, S. Natori +------------------------------------------------------------------------- |More detailed information about the NFS server/client. +------------------------------------------------------------------------- Server spec: CPU: Pentium III 800MHz MEM: 256MB SCSI: Adaptec 29160 Ultra160 SCSI adapter HDD: da0: Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) NIC: Intel Pro 100+ Client fstab: server:/home /home nfs rw,tcp,intr 0 0 server:/usr/local /usr/local nfs rw,tcp,intr 0 0 server:/usr/X11R6 /usr/X11R6 nfs rw,tcp,intr 0 0 server:/usr/compat /usr/compat nfs rw,tcp,intr 0 0 server:/usr/share /usr/share nfs rw,tcp,intr 0 0 +------------------------------------------------------------------------- |Much more detailed information about the hanged nfsds +------------------------------------------------------------------------- USER PID %CPU %MEM ACFLG CPU F INBLK JOBC KTRACE KTRACEP LIM LOGIN STARTED MAJFLT MINFLT MSGRCV MSGSND NI NIVCSW NSIGS NSWAP NVCSW WCHAN OUBLK P_RU PADDR PAGEIN PGID PPID PRI RE RGID RLINK RSS RSZ RTPRIO RUID RUSER SESS PENDING CAUGHT IGNORED BLOCKED SL STARTED STAT SVGID SVUID TDEV TIME TPGID TSESS TSIZ TT TTY UCOMM UID UPR VSZ WCHAN XSTAT COMMAND root 440 0.0 0.1 3 0 84 0 0 0 0 - root Sat 4/ 7 15:16:03 2001 0 20 4 4 0 58 0 0 58 cdae0f6 0 0 e855440 0 440 1 2 5662 0 3ab3e0 132 132 normal 0 root 1808880 0 80800 1840c007 0 525 3:16PM Is 0 0 ?? 0:00.00 0 0 156 ?? ?? nfsd 0 50 360 accept 0 nfsd: master (nfsd) root 441 0.0 0.1 3 0 4 4322 0 0 0 - root Sat 4/ 7 15:16:03 2001 0 23 0 100282 0 0 0 0 104888 17fb700 1569 0 e855ac0 0 440 440 -14 5662 0 3ab298 124 124 normal 0 root 1808880 0 80800 1840c007 0 738 3:16PM D 0 0 ?? 0:03.49 0 0 156 ?? ?? nfsd 0 50 352 inode 0 nfsd: server (nfsd) root 442 0.0 0.1 3 0 4 494 0 0 0 - root Sat 4/ 7 15:16:03 2001 0 7 0 4108 0 0 0 0 4634 17fb700 18 0 e855920 0 440 440 -14 5662 0 e855ac0 124 124 normal 0 root 1808880 0 80800 1840c007 0 738 3:16PM D 0 0 ?? 0:00.17 0 0 156 ?? ?? nfsd 0 50 352 inode 0 nfsd: server (nfsd) root 443 0.0 0.1 3 0 4 58 0 0 0 - root Sat 4/ 7 15:16:03 2001 0 12 0 581 0 0 0 0 696 17fb700 22 0 e855780 0 440 440 -14 5662 0 e855920 124 124 normal 0 root 1808880 0 80800 1840c007 0 738 3:16PM D 0 0 ?? 0:00.02 0 0 156 ?? ?? nfsd 0 50 352 inode 0 nfsd: server (nfsd) root 444 0.0 0.1 3 0 4 17 0 0 0 - root Sat 4/ 7 15:16:03 2001 0 7 0 198 0 0 0 0 271 188fe00 0 0 d4470c0 0 440 440 -14 5662 0 3ab4d0 124 124 normal 0 root 1808880 0 80800 1840c007 0 738 3:16PM D 0 0 ?? 0:00.01 0 0 156 ?? ?? nfsd 0 50 352 inode 0 nfsd: server (nfsd) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 12 0:52:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from waltz.SoftHome.net (waltz.SoftHome.net [204.144.231.7]) by hub.freebsd.org (Postfix) with SMTP id C35EF37B621 for ; Thu, 12 Apr 2001 00:52:42 -0700 (PDT) (envelope-from asr@softhome.net) Received: (qmail 21555 invoked by uid 417); 12 Apr 2001 07:52:39 -0000 Message-ID: <20010412075239.21554.qmail@softhome.net> From: asr@softhome.net To: freebsd-net@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: netinet/accf_http.c usage ? Date: Thu, 12 Apr 2001 07:52:39 GMT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Sender: asr@softhome.net Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I can't seem decipher the functionality of the accf_http.c file in the netinet directory ... I also couldn't find any documents that describe its purpose .... is it an HTTP filter or something like that ? Ashutosh S. Rajekar http://www.rajekar.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 12 1: 1:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id BBFB237B617 for ; Thu, 12 Apr 2001 01:01:01 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 4926 invoked by uid 1000); 12 Apr 2001 07:59:38 -0000 Date: Thu, 12 Apr 2001 10:59:38 +0300 From: Peter Pentchev To: asr@softhome.net Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: netinet/accf_http.c usage ? Message-ID: <20010412105938.C3439@ringworld.oblivion.bg> Mail-Followup-To: asr@softhome.net, freebsd-net@freebsd.org, freebsd-hackers@freebsd.org References: <20010412075239.21554.qmail@softhome.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010412075239.21554.qmail@softhome.net>; from asr@softhome.net on Thu, Apr 12, 2001 at 07:52:39AM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Apr 12, 2001 at 07:52:39AM +0000, asr@softhome.net wrote: > > Hi, > > I can't seem decipher the functionality of the accf_http.c file in the > netinet directory ... I also couldn't find any documents that describe its > purpose .... is it an HTTP filter or something like that ? Have you tried 'man accf_http', or even 'man -k accf_http'? Start with 'man 9 accept_filter', then 'man 9 accf_http'. Hope that clears things up. G'luck, Peter -- You have, of course, just begun reading the sentence that you have just finished reading. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 12 6:49: 2 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from khan.acc.umu.se (khan.acc.umu.se [130.239.18.139]) by hub.freebsd.org (Postfix) with ESMTP id 028BD37B440 for ; Thu, 12 Apr 2001 06:48:58 -0700 (PDT) (envelope-from markush@acc.umu.se) Received: from mao.acc.umu.se (root@mao.acc.umu.se [130.239.18.154]) by khan.acc.umu.se (8.11.2/8.11.2) with ESMTP id f3CDmuc06690; Thu, 12 Apr 2001 15:48:56 +0200 (MEST) Received: (from markush@localhost) by mao.acc.umu.se (8.9.3/8.9.3/Debian 8.9.3-21) id PAA27165; Thu, 12 Apr 2001 15:48:56 +0200 Date: Thu, 12 Apr 2001 15:48:56 +0200 From: Markus Holmberg To: Christoph Kukulies Cc: hackers@FreeBSD.ORG Subject: Re: OUTPORT / outb instructions - where defined? Message-ID: <20010412154855.C21902@acc.umu.se> References: <200104111401.f3BE1OT19399@gilberto.physik.rwth-aachen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3-current-20000511i In-Reply-To: <200104111401.f3BE1OT19399@gilberto.physik.rwth-aachen.de>; from kuku@gilberto.physik.rwth-aachen.de on Wed, Apr 11, 2001 at 04:01:24PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG See /usr/ports/audio/mpmf20. It's for MPMan F-20, might be helpful. Regards, Markus. On Wed, Apr 11, 2001 at 04:01:24PM +0200, Christoph Kukulies wrote: > I'm seeking the header file in FreeBSD which corresponds to asm/io.h > in Linux. It should contain macros like OUTPORT, INPORT etc. > to do direct port io. I want to port a little program > (MPMAN) which can upload files to a MP3 player. > > -- > Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- Markus Holmberg | Give me Unix or give me a typewriter. markush@acc.umu.se | http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 12 9:19: 1 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from netbank.com.br (garrincha.netbank.com.br [200.203.199.88]) by hub.freebsd.org (Postfix) with ESMTP id BD9BD37B440 for ; Thu, 12 Apr 2001 09:18:56 -0700 (PDT) (envelope-from riel@conectiva.com.br) Received: from surriel.ddts.net (1-027.cwb-adsl.brasiltelecom.net.br [200.193.160.27]) by netbank.com.br (Postfix) with ESMTP id 9233E4682E; Thu, 12 Apr 2001 13:18:40 -0300 (BRST) Received: from localhost (ubzefk@localhost [127.0.0.1]) by surriel.ddts.net (8.11.2/8.11.2) with ESMTP id f3CGIbf20708; Thu, 12 Apr 2001 13:18:38 -0300 Date: Thu, 12 Apr 2001 13:18:37 -0300 (BRST) From: Rik van Riel X-Sender: riel@imladris.rielhome.conectiva To: Matt Dillon Cc: David Xu , freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance In-Reply-To: <200104110244.f3B2iHk97869@earth.backplane.com> Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 10 Apr 2001, Matt Dillon wrote: > It's randomness that will kill performance. You know the old saying > about caches: They only work if you get cache hits, otherwise > they only slow things down. I wonder ... how does FreeBSD handle negative directory entries? That is, /bin/sh looks through the PATH to search for some executable (eg grep) and doesn't find it in the first 3 directories. The next time the script is started (it might be ran for every file in a large compile) the next invocation of the script looks for the file in 3 directories where it isn't present .. again. Does the vfs cache handle this or does FreeBSD have to go down into the filesystem code every time? Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 12 10: 5:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 4875537B424 for ; Thu, 12 Apr 2001 10:05:14 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (bill.cs.rpi.edu [128.213.2.2]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id NAA80766 for ; Thu, 12 Apr 2001 13:05:13 -0400 (EDT) Message-Id: <200104121705.NAA80766@cs.rpi.edu> To: freebsd-hackers@freebsd.org Subject: ypserv Date: Thu, 12 Apr 2001 13:05:12 -0400 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, I am able to reproduce the crash pretty reliably, I don't know what is causing it yet, I just kill all the other ypservs on a subnet except for this one and it crashes about once every 5 minutes. I have some questions/theories that I'd like to bounce off of people: 1) In the yp_all function it calls yp_fork() to fork a new ypserv, the parent them calls return(NULL); and the child handles the request. Looking at the ktraces, I notice that the parent does not close the socket connection, but after the child finishes the transaction the parent gets a read() return value of 0 (EOF) for that socket and then closes it. Since this is a yp_all request there _shouldn't_ be any more read data on the socket until the close event (which is a read of 0), but that socket is still open in both the parent and the child, and the child is making calls against it... is there a possibility of some shared data corruption within the RPC code that anyone could think of? 2) The RPC code itself has a lot of checks against blocking... is the forking of ypserv even needed at all? -- David Cross | email: crossd@cs.rpi.edu Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 12 10:31: 1 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 799C837B422 for ; Thu, 12 Apr 2001 10:30:58 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3CHUf419830; Thu, 12 Apr 2001 10:30:41 -0700 (PDT) (envelope-from dillon) Date: Thu, 12 Apr 2001 10:30:41 -0700 (PDT) From: Matt Dillon Message-Id: <200104121730.f3CHUf419830@earth.backplane.com> To: Rik van Riel Cc: David Xu , freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :On Tue, 10 Apr 2001, Matt Dillon wrote: : :> It's randomness that will kill performance. You know the old saying :> about caches: They only work if you get cache hits, otherwise :> they only slow things down. : :I wonder ... how does FreeBSD handle negative directory entries? : :That is, /bin/sh looks through the PATH to search for some executable :(eg grep) and doesn't find it in the first 3 directories. : :Does the vfs cache handle this or does FreeBSD have to go down into :the filesystem code every time? : :Rik The namei cache stores negative hits. /usr/src/sys/kern/vfs_cache.c cache_lookup() - if ncp->nc_vp (the vnode) is NULL, the cache entry represents a negative hit. cache_enter() - vp may be passed as NULL to create a negative cache entry. ufs/ufs/ufs_lookup.c, calls to cache_enter() enters positive or negative lookups as appropriate. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 12 10:43:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 3989F37B440 for ; Thu, 12 Apr 2001 10:43:09 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f3CHggC57994; Thu, 12 Apr 2001 19:42:42 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matt Dillon Cc: Rik van Riel , David Xu , freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance In-Reply-To: Your message of "Thu, 12 Apr 2001 10:30:41 PDT." <200104121730.f3CHUf419830@earth.backplane.com> Date: Thu, 12 Apr 2001 19:42:42 +0200 Message-ID: <57992.987097362@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200104121730.f3CHUf419830@earth.backplane.com>, Matt Dillon writes: > >: >:On Tue, 10 Apr 2001, Matt Dillon wrote: >: >:> It's randomness that will kill performance. You know the old saying >:> about caches: They only work if you get cache hits, otherwise >:> they only slow things down. >: >:I wonder ... how does FreeBSD handle negative directory entries? >: >:That is, /bin/sh looks through the PATH to search for some executable >:(eg grep) and doesn't find it in the first 3 directories. >: >:Does the vfs cache handle this or does FreeBSD have to go down into >:the filesystem code every time? >: >:Rik > > The namei cache stores negative hits. /usr/src/sys/kern/vfs_cache.c > cache_lookup() - if ncp->nc_vp (the vnode) is NULL, the cache entry > represents a negative hit. cache_enter() - vp may be passed as NULL > to create a negative cache entry. ufs/ufs/ufs_lookup.c, calls to > cache_enter() enters positive or negative lookups as appropriate. > You should also know that negative entries, since they have no objects to "hang from" and consequently would clog up the name-cache, are limited by the sysctl: debug.ncnegfactor: 16 which means that max 1/16 of the name cache entries can be negative entries. You can monitor the number of negative entries with the sysctl debug.numneg: 305 the value of "16" was rather arbitrarily chosen and better defaults may exist. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | 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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 12 10:57:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id B6C8037B446 for ; Thu, 12 Apr 2001 10:57:35 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3CHvJd20639; Thu, 12 Apr 2001 10:57:19 -0700 (PDT) (envelope-from dillon) Date: Thu, 12 Apr 2001 10:57:19 -0700 (PDT) From: Matt Dillon Message-Id: <200104121757.f3CHvJd20639@earth.backplane.com> To: Poul-Henning Kamp Cc: Rik van Riel , David Xu , freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance References: <57992.987097362@critter> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :You should also know that negative entries, since they have no :objects to "hang from" and consequently would clog up the name-cache, :are limited by the sysctl: : debug.ncnegfactor: 16 :which means that max 1/16 of the name cache entries can be negative :entries. You can monitor the number of negative entries with the :sysctl : debug.numneg: 305 : :the value of "16" was rather arbitrarily chosen and better defaults :may exist. : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 :phk@FreeBSD.ORG | TCP/IP since RFC 956 Here's an example from a lightly loaded machine that's been up about two months (since I last upgraded its kernel): earth:/home/dillon> sysctl -a | fgrep vfs.cache vfs.cache.numneg: 1596 vfs.cache.numcache: 30557 vfs.cache.numcalls: 352196140 vfs.cache.dothits: 5598866 vfs.cache.dotdothits: 14055093 vfs.cache.numchecks: 435747692 vfs.cache.nummiss: 29963655 vfs.cache.nummisszap: 3042073 vfs.cache.numposzaps: 3308219 vfs.cache.numposhits: 274527703 vfs.cache.numnegzaps: 939714 vfs.cache.numneghits: 20760817 vfs.cache.numcwdcalls: 215565 vfs.cache.numcwdfail1: 29 vfs.cache.numcwdfail2: 1730 vfs.cache.numcwdfail3: 0 vfs.cache.numcwdfail4: 4 vfs.cache.numcwdfound: 213802 vfs.cache.numfullpathcalls: 0 vfs.cache.numfullpathfail1: 0 vfs.cache.numfullpathfail2: 0 vfs.cache.numfullpathfail3: 0 vfs.cache.numfullpathfail4: 0 vfs.cache.numfullpathfound: 0 Again, keep in mind that the namei cache is strictly throw-away, but entries can often be reconstituted later by the filesystem without I/O due to the VM Page cache (and/or buffer cache depending on vfs.vmiodirenable). So as with the buffer cache and inode cache, the number of entries can be limited without killing performance or scaleability. earth:/home/dillon> vmstat -m | egrep 'Type|vfsc' ... Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) vfscache 30567 2386K 2489K 85444K 27552485 0 0 64,128,256,256K This particular machine has 30567 component entries in the namei cache at the moment, eating around 2.3 MB of kernel memory. That makes the namei cache quite efficient. Of course, there are many situations where the namei cache is ineffective, such as on machines with insanely huge mail queues or older usenet news systems that used individual files for article storage, or a squid cache that uses individual files. The ultimate solution is to back the name cache with a filesystem that uses hashed or sorted/indexed directories - one of the few disadvantages that remain with UFS/FFS. I've never found that to be a show stopper, though. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 12 11:13:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from netbank.com.br (garrincha.netbank.com.br [200.203.199.88]) by hub.freebsd.org (Postfix) with ESMTP id 6B34C37B424 for ; Thu, 12 Apr 2001 11:13:02 -0700 (PDT) (envelope-from riel@conectiva.com.br) Received: from surriel.ddts.net (1-027.cwb-adsl.brasiltelecom.net.br [200.193.160.27]) by netbank.com.br (Postfix) with ESMTP id 330D946830; Thu, 12 Apr 2001 15:12:38 -0300 (BRST) Received: from localhost (awzakf@localhost [127.0.0.1]) by surriel.ddts.net (8.11.2/8.11.2) with ESMTP id f3CICgf22988; Thu, 12 Apr 2001 15:12:42 -0300 Date: Thu, 12 Apr 2001 15:12:42 -0300 (BRST) From: Rik van Riel X-Sender: riel@imladris.rielhome.conectiva To: Matt Dillon Cc: Poul-Henning Kamp , David Xu , freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance In-Reply-To: <200104121757.f3CHvJd20639@earth.backplane.com> Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 12 Apr 2001, Matt Dillon wrote: > Again, keep in mind that the namei cache is strictly throw-away, This seems to be the main difference between Linux and FreeBSD. In Linux, open files directly refer to an entry in the dentry (and inode) cache, so we really need to have dynamically growing and shrinking caches in order to accomodate programs that have huge amounts of files open (but we want to free the memory again later, because the system load changes). regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 12 11:49:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.2cactus.com (mail.2cactus.com [198.93.52.67]) by hub.freebsd.org (Postfix) with ESMTP id 107D137B443 for ; Thu, 12 Apr 2001 11:49:51 -0700 (PDT) (envelope-from logan@mail.2cactus.com) Received: from mail.2cactus.com (mail.2cactus.com [198.93.52.67]) by mail.2cactus.com (8.11.1/8.9.3) with ESMTP id f3CIkqh77223; Thu, 12 Apr 2001 11:46:52 -0700 (MST) (envelope-from logan@mail.2cactus.com) Date: Thu, 12 Apr 2001 11:46:52 -0700 (MST) From: Logan Gabriel To: freebsd-hackers@FreeBSD.org Subject: Kernel malloc problems with M_NOWAIT. Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-329173002-987101212=:77198" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-329173002-987101212=:77198 Content-Type: TEXT/PLAIN; charset=US-ASCII There is a hard to duplicate race condition in freebsd's kernel malloc. Bassically it is possiables for the kernel to tsleep way down in vm_page_sleep_busy even when M_NOWAIT is spefcied. Under some conditions this can block the kernel completly. Attatched is a kernel module that demonstrates this rare condition, The module has been tested on 4.2-RELEASE generic kernel configurations as well as -STABLE. The module only seems to work about one out of every 10 or 15 tries which makes me think there is a race condition happening. # ps -l -N ./kernel.31 -M ./vmcore.31 UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 0 474 332 0 -18 0 176 0 vmopar D+ #C1 0:00.00 (kldload) 0 477 333 0 -18 0 1372 0 thrd_s DV+ #C9 0:00.00 (csh) (kgdb) proc 474 (kgdb) bt #0 mi_switch () at ../../kern/kern_synch.c:858 #1 0xc016e0d9 in tsleep (ident=0xc05e0794, priority=4, wmesg=0xc02decd1 "vmopar", timo=0) at ../../kern/kern_synch.c:467 #2 0xc0245fbf in vm_object_page_remove (object=0xc0352cc0, start=6882, end=6907, clean_only=0) at ../../vm/vm_page.h:565 #3 0xc0242506 in vm_map_delete (map=0xc0352b60, start=3248361472, end=3248463872) at ../../vm/vm_map.c:1809 #4 0xc02406af in kmem_malloc (map=0xc0352b60, size=102400, flags=1) at ../../vm/vm_kern.c:365 #5 0xc0166bc7 in malloc (size=100000, type=0xc191d840, flags=1) at ../../kern/kern_malloc.c:188 #6 0xc191c6da in ?? () #7 0xc015b49b in module_register_init (arg=0xc191d824) at ../../kern/kern_module.c:109 #8 0xc015ba57 in linker_file_sysinit (lf=0xc190fa80) at ../../kern/kern_linker.c:151 #9 0xc015bbd8 in linker_load_file (filename=0xc18e1800 "./test_module_nowait_42_generic.ko", result=0xd3f28f28) at ../../kern/kern_linker.c:285 #10 0xc015c422 in kldload (p=0xd2b8e400, uap=0xd3f28f80) at ../../kern/kern_linker.c:678 #11 0xc02a6e09 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 1, tf_ebp = -1077937200, tf_isp = -739078188, tf_ebx = -1077937112, tf_edx = 0, tf_ecx = 134559200, tf_eax = 304, tf_trapno = 12, tf_err = 2, tf_eip = 134513812, tf_cs = 31, tf_eflags = 647, tf_esp = -1077937244, tf_ss = 47}) at ../../i386/i386/trap.c:1150 #12 0xc029b195 in Xint0x80_syscall () #13 0x8048135 in ?? () # vmstat -m -N ./kernel.31 -M ./vmcore.31 | tail -2 Memory Totals: In Use Free Requests 2315K 50K 322928 --0-329173002-987101212=:77198 Content-Type: APPLICATION/x-tar-gz; name="malloc.tgz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="malloc.tgz" H4sIAG+V1ToAA+1Ye2+bSBDPv+FTTEmq4MR1AGP7FCeRHNvtWfGj8kOn07Wi GJYYGYMF+JI0zXe/2QXjBzSprqnb0/GTkNnZmZ2Z3ZllxjPNtl1dnbnGwian ez8EoIgVUYQ9AKlSYr+I5W80gIpcVoqKIioSssmyJO1B6ceYs4mFH2gewN4N 8fzJE3y3E0LsXRi0W8w2zn+mWU5Bf2kdkiiWFeWr518si/H5FytKCdmKiozn L760IWn4n5//geXo9sIgcO7f+6dzzdNmhcklt0nGJ0ghT4nnEDtJD2Mqhc6C LEkP7ufET5IXlpskzr20lfHBiYDxr6Z4Fs4Tfo2iGYZHfJ8SOTz4wNLBD7yF HsB0RmbjhT4lgQ/H4QtcgJA2m6s1Gv3mYFCN1wg9M7RAU4O1AS7wwNEQ5wPi B1GS8XlGCgcqcQLvPqSI3GN12yomp3vanL39Ney3moOPyNWptdu9utpovm11 m0JHrfdr76U88HXKKvHLN2aExOeqqQLykk3eFJCpAGc5AbdupBAO8kCPKw+O G0ws5ya37szS9yoj4gKMNxz97VoGHEdSVS7cl8hZfYIpeMzcvIDuqN1eLeBb n1GZj1q9e5wUq5Fc8lSm43k4abvODcoadyjkBppteoSEoqHsrRXoExCoaaH1 oS0UuuYT6PQaartXa5xxMZ3J4Rr+3J5YNxMhV92ci0wPA1+QKr9JlXIe4l3u qH/UWsPe9baY6XpoR+QY8/DVBbAzZqOTk9wG+8PGiCLNv4QCuhWhBvZ2Dp1W 92pUv24O4QSkckhGXZAQTypkG4FHgutJcH7ORKupXHgcyBQl0skTjCsfTi7C tY+p8JvL6ViN55Kij0lv5x5GjCnwQ+/+DF4bMKTSwJb255pOwPLhtW1cf3B4 Fk/5Z+w5BUmUle1Do7BMEASWkbjMx8J4YZrEWwVAvMQyBqR0VR2126ORkcvB RRj4uW88gzVX0dMzGE4IMN2YT64DpmbhDbT0M/dNu4exfSf4W7yP3P7YI9oU qckkGXXDNFkX+O6Qplub2NlXX9sdphI3OiES73zCoYQoTd44WdfYl46vtssj wcJzaKYhodGst2v9poo7MWo3hbUbPr/2CcjDoKUORlfq+0Fz1OixYa/faPbV WvdPVPazv/+b9V9HmxITQ+dldTxT/0GxWIrqv6Issfq/WClWsvpvFxj06wN2 cdHCn7vGYMbRWixz9bft2rsBvZvfNLB8uBq94ziMmTOISikchS9n3L4zg09Y iumBDbQ2LIxdN6DhBF9Au53C0QO7tuDwUH48+oTEG4/MgR9HXwkePnD7m5z8 gYHx6BCIKi4Q7/jDQ+nxCC4hLuU4rhAXg2PfKEzR8sJsipXgz97c/wBS+r+n suBf4bn8L1WkZf8ny0qZ9X9iKcv/XeDAMh3MMVA7tVZX/Z1bJtxyvN1+vUyD uKNGMPKFlR+slqPt1VZf9cDth+1HWDdUWRMWd0vsEy+sSonUCVo00NsqpVtS gzxtY/JR+0NryQPiGJb5q9xNm/kf36kvquO5/McCYPX/T1lGNkUsF7P83wWS H1hdLGqyKYu/SoRmyJAhQ4YMGTJkyJAhQ4YMGTJk+B78AzaYzwwAKAAA --0-329173002-987101212=:77198-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 12 13:18: 1 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 12F4137B424 for ; Thu, 12 Apr 2001 13:17:58 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3CKHvG19152; Thu, 12 Apr 2001 13:17:57 -0700 (PDT) Date: Thu, 12 Apr 2001 13:17:57 -0700 From: Alfred Perlstein To: Logan Gabriel Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel malloc problems with M_NOWAIT. Message-ID: <20010412131757.J24582@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from logan@mail.2cactus.com on Thu, Apr 12, 2001 at 11:46:52AM -0700 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Logan Gabriel [010412 11:50] wrote: > There is a hard to duplicate race condition in freebsd's > kernel malloc. Bassically it is possiables for the kernel > to tsleep way down in vm_page_sleep_busy even when M_NOWAIT > is spefcied. Under some conditions this can block the kernel > completly. > > Attatched is a kernel module that demonstrates this rare condition, > The module has been tested on 4.2-RELEASE generic kernel configurations > as well as -STABLE. The module only seems to work about one out of every > 10 or 15 tries which makes me think there is a race condition happening. > Please try the attached patch: Index: vm_kern.c =================================================================== RCS file: /home/ncvs/src/sys/vm/vm_kern.c,v retrieving revision 1.61.2.1 diff -u -r1.61.2.1 vm_kern.c --- vm_kern.c 2000/08/04 22:31:11 1.61.2.1 +++ vm_kern.c 2001/04/12 20:19:17 @@ -362,7 +362,7 @@ vm_map_lock(map); goto retry; } - vm_map_delete(map, addr, addr + size); + vm_map_delete(map, addr, addr + (i - PAGE_SIZE)); vm_map_unlock(map); if (flags & M_ASLEEP) { VM_AWAIT; if it bombs please try: Index: vm_kern.c =================================================================== RCS file: /home/ncvs/src/sys/vm/vm_kern.c,v retrieving revision 1.61.2.1 diff -u -r1.61.2.1 vm_kern.c --- vm_kern.c 2000/08/04 22:31:11 1.61.2.1 +++ vm_kern.c 2001/04/12 20:19:59 @@ -362,7 +362,7 @@ vm_map_lock(map); goto retry; } - vm_map_delete(map, addr, addr + size); + vm_map_delete(map, addr, addr + i); vm_map_unlock(map); if (flags & M_ASLEEP) { VM_AWAIT; -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 12 13:51:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id CF9A037B449 for ; Thu, 12 Apr 2001 13:51:12 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f3CKooC59190; Thu, 12 Apr 2001 22:50:51 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matt Dillon Cc: Rik van Riel , David Xu , freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance In-Reply-To: Your message of "Thu, 12 Apr 2001 10:57:19 PDT." <200104121757.f3CHvJd20639@earth.backplane.com> Date: Thu, 12 Apr 2001 22:50:50 +0200 Message-ID: <59188.987108650@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200104121757.f3CHvJd20639@earth.backplane.com>, Matt Dillon writes: > Again, keep in mind that the namei cache is strictly throw-away, but > entries can often be reconstituted later by the filesystem without I/O > due to the VM Page cache (and/or buffer cache depending on > vfs.vmiodirenable). So as with the buffer cache and inode cache, > the number of entries can be limited without killing performance or > scaleability. Uhm, that is actually not true. We keep namecache entries around as long as we can use them, and that generally means that recreating them is a rather expensive operation, involving creation of vnode and very likely a vm object again. We can safely say that you cannot profitably _increase_ the size of the namecache, except for the negative entries where raw statistics will have to be the judge of the profitability of the idea. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | 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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 12 13:53:51 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id DB79937B449 for ; Thu, 12 Apr 2001 13:53:46 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3CKrZ424106; Thu, 12 Apr 2001 13:53:35 -0700 (PDT) (envelope-from dillon) Date: Thu, 12 Apr 2001 13:53:35 -0700 (PDT) From: Matt Dillon Message-Id: <200104122053.f3CKrZ424106@earth.backplane.com> To: Poul-Henning Kamp Cc: Rik van Riel , David Xu , freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance References: <59188.987108650@critter> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :In message <200104121757.f3CHvJd20639@earth.backplane.com>, Matt Dillon writes: : :> Again, keep in mind that the namei cache is strictly throw-away, but :> entries can often be reconstituted later by the filesystem without I/O :> due to the VM Page cache (and/or buffer cache depending on :> vfs.vmiodirenable). So as with the buffer cache and inode cache, :> the number of entries can be limited without killing performance or :> scaleability. : :Uhm, that is actually not true. : :We keep namecache entries around as long as we can use them, and that :generally means that recreating them is a rather expensive operation, :involving creation of vnode and very likely a vm object again. The vnode cache is a different cache. positive namei hits will reference a vnode, but namei elements can be flushed at any time without flushing the underlying vnode. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 12 13:56: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 6FCE937B422 for ; Thu, 12 Apr 2001 13:56:00 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f3CKtaC59489; Thu, 12 Apr 2001 22:55:36 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matt Dillon Cc: Rik van Riel , David Xu , freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance In-Reply-To: Your message of "Thu, 12 Apr 2001 13:53:35 PDT." <200104122053.f3CKrZ424106@earth.backplane.com> Date: Thu, 12 Apr 2001 22:55:36 +0200 Message-ID: <59487.987108936@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200104122053.f3CKrZ424106@earth.backplane.com>, Matt Dillon writes: > >: >:In message <200104121757.f3CHvJd20639@earth.backplane.com>, Matt Dillon writes: >: >:> Again, keep in mind that the namei cache is strictly throw-away, but >:> entries can often be reconstituted later by the filesystem without I/O >:> due to the VM Page cache (and/or buffer cache depending on >:> vfs.vmiodirenable). So as with the buffer cache and inode cache, >:> the number of entries can be limited without killing performance or >:> scaleability. >: >:Uhm, that is actually not true. >: >:We keep namecache entries around as long as we can use them, and that >:generally means that recreating them is a rather expensive operation, >:involving creation of vnode and very likely a vm object again. > > The vnode cache is a different cache. positive namei hits will > reference a vnode, but namei elements can be flushed at any > time without flushing the underlying vnode. Right, but doing so means that to refind that vnode from the name is (comparatively) very expensive. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | 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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 12 14:11:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 5159937B446; Thu, 12 Apr 2001 14:11:52 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3CLBdc25565; Thu, 12 Apr 2001 14:11:39 -0700 (PDT) (envelope-from dillon) Date: Thu, 12 Apr 2001 14:11:39 -0700 (PDT) From: Matt Dillon Message-Id: <200104122111.f3CLBdc25565@earth.backplane.com> To: "S. Natori" Cc: FreeBSD-questions@FreeBSD.ORG, FreeBSD-hackers@FreeBSD.ORG Subject: Re: nfsd hangs in ``inode'' state References: <200104120423.NAA15537@mail.fureai.or.jp> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Hello All, : :I am running a FreeBSD-4.2 NFS server with dozens of FreeBSD-4.2 NFS :clients on 100BaseTX LAN. Recently I found that when the NFS server :receives a lot of requests in a short period (e.g., 2 clients start X :with gnome desktop simultaneously), all nfsd server processes hang in :inode state. : : UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND : 0 440 1 0 2 0 360 132 accept Is ?? 0:00.00 nfsd: master (nfsd) : 0 441 440 0 -14 0 352 124 inode D ?? 0:03.49 nfsd: server (nfsd) : 0 442 440 0 -14 0 352 124 inode D ?? 0:00.17 nfsd: server (nfsd) : 0 443 440 0 -14 0 352 124 inode D ?? 0:00.02 nfsd: server (nfsd) : 0 444 440 0 -14 0 352 124 inode D ?? 0:00.01 nfsd: server (nfsd) : :I cannot kill or restart them. The consoles of the clients print ``NFS :server not responding'' and I should restart the server. This occurs :about once a week. : :I tried : (1) increasing the number of nfsd processes (4 -> 8, 20) : (2) replacing the server HDD (SCSI) with another ATA33 HDD : (3) changing mount_nfs options (tried removing tcp, adding soft,dumbtimer) :but all failed to solve the problem. It sounds like a deadlock somewhere, probably with some other process. A full 'ps axlww' would be useful, and also a gdb backtrace of the processes in question (including the 'other' process stuck in some weird wait state if you can find it). You can gdb a live kernel in a meaningful fashion if you have the kernel.debug image of the kernel available somewhere. gdb -k /dev/mem proc 441 back proc 442 back proc 443 back proc 444 back proc back -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 12 14:21:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gandalf.vi.bravenet.com (gandalf.bravenet.com [139.142.105.50]) by hub.freebsd.org (Postfix) with SMTP id 3210437B43E for ; Thu, 12 Apr 2001 14:21:31 -0700 (PDT) (envelope-from dphoenix@bravenet.com) Received: (qmail 28559 invoked by uid 1000); 12 Apr 2001 21:21:25 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 12 Apr 2001 21:21:25 -0000 Date: Thu, 12 Apr 2001 14:21:25 -0700 (PDT) From: Dan Phoenix To: freebsd-hackers@freebsd.org Subject: apc and apache Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ;;;;;;;;;;;;;;;;; ; APC ; ;;;;;;;;;;;;;;;;; apc.cachedir="/usr/cache" apc.relative_includes= 1 apc.check_mtime = 1 threw that in the php.ini file. Started apache and booom webservers went to hell...each httpd taking 20 megs or more on a couple webservers. Anyone experience this? Commenting those lines out and restarting apache put everything back to normal. And yes /usr/cache is writeable....and no website files are not even by owner who runs apache. -- Dan +------------------------------------------------------+ | BRAVENET WEB SERVICES | | dan@bravenet.com | | make installworld | | ln -s /var/qmail/bin/sendmail /usr/sbin/sendmail | | ln -s /var/qmail/bin/newaliases /usr/sbin/newaliases | +______________________________________________________+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 12 14:25:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gandalf.vi.bravenet.com (gandalf.bravenet.com [139.142.105.50]) by hub.freebsd.org (Postfix) with SMTP id C85F637B43F for ; Thu, 12 Apr 2001 14:25:46 -0700 (PDT) (envelope-from dphoenix@bravenet.com) Received: (qmail 24985 invoked by uid 1000); 12 Apr 2001 21:25:46 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 12 Apr 2001 21:25:46 -0000 Date: Thu, 12 Apr 2001 14:25:46 -0700 (PDT) From: Dan Phoenix To: freebsd-hackers@freebsd.org Subject: Re: apc and apache In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG To update on this one box... PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 2399 bravenet 2 0 17364K 15540K accept 0:00 1.07% 0.83% httpd 2401 bravenet 2 0 20304K 18980K accept 0:00 1.01% 0.78% httpd 2446 bravenet 2 0 16468K 14828K accept 0:00 1.01% 0.78% httpd this is the memory with apc enabled!...will kill the machine here is normal with apc turned off 2575 bravenet 2 0 6040K 5100K sbwait 0:00 1.30% 0.98% httpd 2533 bravenet 2 0 6000K 5100K accept 0:00 1.10% 0.83% httpd unreal! On Thu, 12 Apr 2001, Dan Phoenix wrote: > Date: Thu, 12 Apr 2001 14:21:25 -0700 (PDT) > From: Dan Phoenix > To: freebsd-hackers@freebsd.org > Subject: apc and apache > > > ;;;;;;;;;;;;;;;;; > ; APC ; > ;;;;;;;;;;;;;;;;; > > apc.cachedir="/usr/cache" > apc.relative_includes= 1 > apc.check_mtime = 1 > > threw that in the php.ini file. > > Started apache and booom webservers went to hell...each httpd taking > 20 megs or more on a couple webservers. Anyone experience this? > Commenting those lines out and restarting apache put everything back to > normal. > > And yes /usr/cache is writeable....and no website files are not even by > owner who runs apache. > > > > -- > Dan > > +------------------------------------------------------+ > | BRAVENET WEB SERVICES | > | dan@bravenet.com | > | make installworld | > | ln -s /var/qmail/bin/sendmail /usr/sbin/sendmail | > | ln -s /var/qmail/bin/newaliases /usr/sbin/newaliases | > +______________________________________________________+ > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 12 14:26:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 0FDEC37B422 for ; Thu, 12 Apr 2001 14:26:18 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3CLOaq25845; Thu, 12 Apr 2001 14:24:36 -0700 (PDT) (envelope-from dillon) Date: Thu, 12 Apr 2001 14:24:36 -0700 (PDT) From: Matt Dillon Message-Id: <200104122124.f3CLOaq25845@earth.backplane.com> To: Poul-Henning Kamp Cc: Rik van Riel , David Xu , freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance References: <59487.987108936@critter> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :>:> scaleability. :>: :>:Uhm, that is actually not true. :>: :>:We keep namecache entries around as long as we can use them, and that :>:generally means that recreating them is a rather expensive operation, :>:involving creation of vnode and very likely a vm object again. :> :> The vnode cache is a different cache. positive namei hits will :> reference a vnode, but namei elements can be flushed at any :> time without flushing the underlying vnode. : :Right, but doing so means that to refind that vnode from the name :is (comparatively) very expensive. : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 :phk@FreeBSD.ORG | TCP/IP since RFC 956 The only thing that is truely expensive is having to physically scan a large directory in order to instantiate a new namei record. Everything else is inexpensive by comparison (by two orders of magnitude!), even constructing new vnodes. Without vmiodirenable turned on, any directory exceeding vfs.maxmallocbufspace becomes extremely expensive to work with O(N * diskIO). With vmiodirenable turned on huge directories are O(N), but have a better chance of being in the VM page cache so cost proportionally less even though they don't do any better on a relative scale. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 12 14:35:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from gandalf.vi.bravenet.com (gandalf.bravenet.com [139.142.105.50]) by hub.freebsd.org (Postfix) with SMTP id E965337B449 for ; Thu, 12 Apr 2001 14:35:20 -0700 (PDT) (envelope-from dphoenix@bravenet.com) Received: (qmail 25619 invoked by uid 1000); 12 Apr 2001 21:35:20 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 12 Apr 2001 21:35:20 -0000 Date: Thu, 12 Apr 2001 14:35:20 -0700 (PDT) From: Dan Phoenix To: freebsd-hackers@freebsd.org Subject: Re: apc and apache In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hmmm i made all website files owned by apache owner and all was normal! i told apc not to write to my webfiles yet it does anyways. Anyone see anything fishy going on here? On Thu, 12 Apr 2001, Dan Phoenix wrote: > Date: Thu, 12 Apr 2001 14:25:46 -0700 (PDT) > From: Dan Phoenix > To: freebsd-hackers@freebsd.org > Subject: Re: apc and apache > > > > To update on this one box... > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND > 2399 bravenet 2 0 17364K 15540K accept 0:00 1.07% 0.83% httpd > 2401 bravenet 2 0 20304K 18980K accept 0:00 1.01% 0.78% httpd > 2446 bravenet 2 0 16468K 14828K accept 0:00 1.01% 0.78% httpd > > this is the memory with apc enabled!...will kill the machine > > here is normal with apc turned off > > 2575 bravenet 2 0 6040K 5100K sbwait 0:00 1.30% 0.98% httpd > 2533 bravenet 2 0 6000K 5100K accept 0:00 1.10% 0.83% httpd > > unreal! > > > > On Thu, 12 Apr 2001, Dan Phoenix wrote: > > > Date: Thu, 12 Apr 2001 14:21:25 -0700 (PDT) > > From: Dan Phoenix > > To: freebsd-hackers@freebsd.org > > Subject: apc and apache > > > > > > ;;;;;;;;;;;;;;;;; > > ; APC ; > > ;;;;;;;;;;;;;;;;; > > > > apc.cachedir="/usr/cache" > > apc.relative_includes= 1 > > apc.check_mtime = 1 > > > > threw that in the php.ini file. > > > > Started apache and booom webservers went to hell...each httpd taking > > 20 megs or more on a couple webservers. Anyone experience this? > > Commenting those lines out and restarting apache put everything back to > > normal. > > > > And yes /usr/cache is writeable....and no website files are not even by > > owner who runs apache. > > > > > > > > -- > > Dan > > > > +------------------------------------------------------+ > > | BRAVENET WEB SERVICES | > > | dan@bravenet.com | > > | make installworld | > > | ln -s /var/qmail/bin/sendmail /usr/sbin/sendmail | > > | ln -s /var/qmail/bin/newaliases /usr/sbin/newaliases | > > +______________________________________________________+ > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 12 17: 0:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from web12505.mail.yahoo.com (web12505.mail.yahoo.com [216.136.173.197]) by hub.freebsd.org (Postfix) with SMTP id 2C9B737B43E for ; Thu, 12 Apr 2001 17:00:33 -0700 (PDT) (envelope-from captonline@yahoo.com) Message-ID: <20010413000032.12100.qmail@web12505.mail.yahoo.com> Received: from [216.127.1.197] by web12505.mail.yahoo.com; Thu, 12 Apr 2001 17:00:32 PDT Date: Thu, 12 Apr 2001 17:00:32 -0700 (PDT) From: Tom Subject: cdr and cdrw with 4.3 release To: hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Does anyone know if it is possible to use a cdr/cdrw with 4.3 release? I want to use it with my sony vaio f580 (notebook). I have the option of usb or pcmcia. Can you tell me which models are known to work? Thanks for your help. Please mail all responses to captonline@yahoo.com. Thanks again.. Tom __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 12 17: 1:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from luke.immure.com (luke.immure.com [207.8.42.74]) by hub.freebsd.org (Postfix) with ESMTP id 097EA37B424; Thu, 12 Apr 2001 17:01:13 -0700 (PDT) (envelope-from bob@luke.immure.com) Received: (from bob@localhost) by luke.immure.com (8.11.2/8.11.3) id f3D01Bf08890; Thu, 12 Apr 2001 19:01:11 -0500 (CDT) (envelope-from bob) Date: Thu, 12 Apr 2001 19:01:11 -0500 From: Bob Willcox To: Mike Smith Cc: Sam Leffler , hackers@FreeBSD.ORG Subject: Re: if_fxp - the real point Message-ID: <20010412190111.A8686@luke.immure.com> Reply-To: Bob Willcox References: <09d901c0a8c0$e2bfed30$24a6d4d1@melange> <200103091823.f29INLs06070@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103091823.f29INLs06070@mass.dis.org>; from msmith@FreeBSD.ORG on Fri, Mar 09, 2001 at 10:23:21AM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am still using a number of these boards in our test environment every day. The fxp driver always complains but it hasn't stopped the nic from working yet. I simply ignore the messages... Bob On Fri, Mar 09, 2001 at 10:23:21AM -0800, Mike Smith wrote: > > What board is this? > > If this is the board I think it is, it's a Supermicro P6DLE dual Slot-1 > motherboard with an integrated Intel 82559 (no external PHY). > > (I had this board for some time before I gave it to David, it was > originally donated to FTL by Bob Willcox.) > > > Sam > > > > ----- Original Message ----- > > From: "David O'Brien" > > To: "Alex Zepeda" > > Cc: > > Sent: Friday, March 09, 2001 4:42 AM > > Subject: Re: if_fxp - the real point > > > > > > > On Thu, Mar 08, 2001 at 06:13:07PM -0800, Alex Zepeda wrote: > > > > However, there *ARE* some of us who aren't intimate with your fxp > > > > problems. > > > > > > The problem does exist. I have a board that the `fxp' driver splits this > > > out for: > > > > > > fxp0: warning: unsupported PHY, type = 17, addr = 2 > > > fxp1: warning: unsupported PHY, type = 17, addr = 2 > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > -- > ... every activity meets with opposition, everyone who acts has his > rivals and unfortunately opponents also. But not because people want > to be opponents, rather because the tasks and relationships force > people to take different points of view. [Dr. Fritz Todt] > V I C T O R Y N O T V E N G E A N C E > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- Bob Willcox The reason we come up with new versions is not to bob@vieo.com fix bugs. It's absolutely not. Austin, TX -- Bill Gates To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 13 0:30:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 0300B37B423 for ; Fri, 13 Apr 2001 00:30:11 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f3D7SRC64015; Fri, 13 Apr 2001 09:28:27 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matt Dillon Cc: Rik van Riel , David Xu , freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance In-Reply-To: Your message of "Thu, 12 Apr 2001 14:24:36 PDT." <200104122124.f3CLOaq25845@earth.backplane.com> Date: Fri, 13 Apr 2001 09:28:27 +0200 Message-ID: <64013.987146907@critter> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200104122124.f3CLOaq25845@earth.backplane.com>, Matt Dillon writes: >:>:> scaleability. >:>: >:>:Uhm, that is actually not true. >:>: >:>:We keep namecache entries around as long as we can use them, and that >:>:generally means that recreating them is a rather expensive operation, >:>:involving creation of vnode and very likely a vm object again. >:> >:> The vnode cache is a different cache. positive namei hits will >:> reference a vnode, but namei elements can be flushed at any >:> time without flushing the underlying vnode. >: >:Right, but doing so means that to refind that vnode from the name >:is (comparatively) very expensive. >: >:-- >:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >:phk@FreeBSD.ORG | TCP/IP since RFC 956 > > The only thing that is truely expensive is having to physically > scan a large directory in order to instantiate a new namei > record. Everything else is inexpensive by comparison (by two > orders of magnitude!), even constructing new vnodes. > > Without vmiodirenable turned on, any directory [...] It's worse than that, we are still way too rude in throwing away directory data... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | 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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 13 0:46:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ajax1.sovam.com (ajax1.sovam.com [194.67.1.172]) by hub.freebsd.org (Postfix) with ESMTP id 39FAB37B423 for ; Fri, 13 Apr 2001 00:46:20 -0700 (PDT) (envelope-from avn@any.ru) Received: from ts11-a135.dial.sovam.com ([195.239.68.135]:1057 "EHLO ts11-a135.dial.sovam.com" ident: "avn" whoson: "-unregistered-" smtp-auth: TLS-CIPHER: TLS-PEER: ) by ajax1.sovam.com with ESMTP id ; Fri, 13 Apr 2001 11:46:06 +0400 Date: Fri, 13 Apr 2001 11:45:24 +0400 (MSD) From: "Alexey V. Neyman" X-X-Sender: To: Subject: HPFS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello there! Is HPFS broken? If not, why is it disabled? # Alexey -------------------------------------+------------------------------ "May the Sun and Water gently | mailto: avn@any.ru fall upon you!" (Supox, from SC2) | -------------------------------------+------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 13 2:39:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (rina.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id 27F5137B42C for ; Fri, 13 Apr 2001 02:39:19 -0700 (PDT) (envelope-from tanimura@r.dl.itc.u-tokyo.ac.jp) Received: from rina.r.dl.itc.u-tokyo.ac.jp (localhost [127.0.0.1]) by rina.r.dl.itc.u-tokyo.ac.jp (8.11.3+3.4W/3.7W-rina.r-20010412) with ESMTP id f3D9d7Z37169 ; Fri, 13 Apr 2001 18:39:08 +0900 (JST) Message-Id: <200104130939.f3D9d7Z37169@rina.r.dl.itc.u-tokyo.ac.jp> Date: Fri, 13 Apr 2001 18:39:07 +0900 From: Seigo Tanimura To: phk@critter.freebsd.dk Cc: dillon@earth.backplane.com, riel@conectiva.com.br, bsddiy@21cn.com, Tor.Egge@fast.no, freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance In-Reply-To: In your message of "Thu, 12 Apr 2001 22:50:50 +0200" <59188.987108650@critter> References: <200104121757.f3CHvJd20639@earth.backplane.com> <59188.987108650@critter> Cc: Seigo Tanimura User-Agent: Wanderlust/1.1.1 (Purple Rain) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Digital Library Research Division, Information Techinology Centre, The University of Tokyo MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 12 Apr 2001 22:50:50 +0200, Poul-Henning Kamp said: Poul-Henning> We keep namecache entries around as long as we can use them, and that Poul-Henning> generally means that recreating them is a rather expensive operation, Poul-Henning> involving creation of vnode and very likely a vm object again. Holding a namecache entry forever until its vnode is reused results in disaster when a huge number of files are accessed concurrently, causing active vnodes to eat up all of memory. This beast killed a box of mine with 3GB of memory and 200GB of a RAID0 disk array serving about 300,000 files by cvsupd and making the world a few months ago, when the number of the vnodes reached around 400,000 to make all of the processes wait for a free vnode. With a help by tegge, the box is now reclaiming directory vnodes when few free vnodes are available. Only directory vnodes holding no child directory vnodes held in v_cache_src are recycled, so that directory vnodes near the root of the filesystem hierarchy remain in namecache and directory vnodes are not reclaimed in cascade. The number of vnodes in the box is now about 135,000, staying quite steadily. Name'cache' is the place to hold vnodes for future use which may *not* come, hence vnodes held in namecache should be reclaimed in case of critical vnode shortage. -- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 13 2:58:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 2878F37B506 for ; Fri, 13 Apr 2001 02:58:24 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3D9w7I09031; Fri, 13 Apr 2001 02:58:07 -0700 (PDT) Date: Fri, 13 Apr 2001 02:58:07 -0700 From: Alfred Perlstein To: Seigo Tanimura Cc: phk@critter.freebsd.dk, dillon@earth.backplane.com, riel@conectiva.com.br, bsddiy@21cn.com, Tor.Egge@fast.no, freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance Message-ID: <20010413025806.A976@fw.wintelcom.net> References: <200104121757.f3CHvJd20639@earth.backplane.com> <59188.987108650@critter> <200104130939.f3D9d7Z37169@rina.r.dl.itc.u-tokyo.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104130939.f3D9d7Z37169@rina.r.dl.itc.u-tokyo.ac.jp>; from tanimura@r.dl.itc.u-tokyo.ac.jp on Fri, Apr 13, 2001 at 06:39:07PM +0900 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Seigo Tanimura [010413 02:39] wrote: > On Thu, 12 Apr 2001 22:50:50 +0200, > Poul-Henning Kamp said: > > Poul-Henning> We keep namecache entries around as long as we can use them, and that > Poul-Henning> generally means that recreating them is a rather expensive operation, > Poul-Henning> involving creation of vnode and very likely a vm object again. > > Holding a namecache entry forever until its vnode is reused results in > disaster when a huge number of files are accessed concurrently, causing > active vnodes to eat up all of memory. This beast killed a box of mine > with 3GB of memory and 200GB of a RAID0 disk array serving about > 300,000 files by cvsupd and making the world a few months ago, when > the number of the vnodes reached around 400,000 to make all of the > processes wait for a free vnode. > > With a help by tegge, the box is now reclaiming directory vnodes when > few free vnodes are available. Only directory vnodes holding no child > directory vnodes held in v_cache_src are recycled, so that directory > vnodes near the root of the filesystem hierarchy remain in namecache > and directory vnodes are not reclaimed in cascade. The number of > vnodes in the box is now about 135,000, staying quite steadily. > > Name'cache' is the place to hold vnodes for future use which may *not* > come, hence vnodes held in namecache should be reclaimed in case of > critical vnode shortage. Are these changes planned for integration? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 13 4: 9: 6 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (rina.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id BB8E337B424 for ; Fri, 13 Apr 2001 04:09:01 -0700 (PDT) (envelope-from tanimura@r.dl.itc.u-tokyo.ac.jp) Received: from rina.r.dl.itc.u-tokyo.ac.jp (localhost [127.0.0.1]) by rina.r.dl.itc.u-tokyo.ac.jp (8.11.3+3.4W/3.7W-rina.r-20010412) with ESMTP id f3DB8vZ49897 ; Fri, 13 Apr 2001 20:08:58 +0900 (JST) Message-Id: <200104131108.f3DB8vZ49897@rina.r.dl.itc.u-tokyo.ac.jp> Date: Fri, 13 Apr 2001 20:08:57 +0900 From: Seigo Tanimura To: bright@wintelcom.net Cc: tanimura@r.dl.itc.u-tokyo.ac.jp, phk@critter.freebsd.dk, dillon@earth.backplane.com, riel@conectiva.com.br, bsddiy@21cn.com, Tor.Egge@fast.no, freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance In-Reply-To: In your message of "Fri, 13 Apr 2001 02:58:07 -0700" <20010413025806.A976@fw.wintelcom.net> References: <200104121757.f3CHvJd20639@earth.backplane.com> <59188.987108650@critter> <200104130939.f3D9d7Z37169@rina.r.dl.itc.u-tokyo.ac.jp> <20010413025806.A976@fw.wintelcom.net> Cc: Seigo Tanimura User-Agent: Wanderlust/1.1.1 (Purple Rain) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Digital Library Research Division, Information Techinology Centre, The University of Tokyo MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 13 Apr 2001 02:58:07 -0700, Alfred Perlstein said: Alfred> * Seigo Tanimura [010413 02:39] wrote: >> On Thu, 12 Apr 2001 22:50:50 +0200, >> Poul-Henning Kamp said: >> >> Poul-Henning> We keep namecache entries around as long as we can use them, and that >> Poul-Henning> generally means that recreating them is a rather expensive operation, >> Poul-Henning> involving creation of vnode and very likely a vm object again. >> >> Holding a namecache entry forever until its vnode is reused results in >> disaster when a huge number of files are accessed concurrently, causing >> active vnodes to eat up all of memory. This beast killed a box of mine >> with 3GB of memory and 200GB of a RAID0 disk array serving about >> 300,000 files by cvsupd and making the world a few months ago, when >> the number of the vnodes reached around 400,000 to make all of the >> processes wait for a free vnode. >> >> With a help by tegge, the box is now reclaiming directory vnodes when >> few free vnodes are available. Only directory vnodes holding no child >> directory vnodes held in v_cache_src are recycled, so that directory >> vnodes near the root of the filesystem hierarchy remain in namecache >> and directory vnodes are not reclaimed in cascade. The number of >> vnodes in the box is now about 135,000, staying quite steadily. >> >> Name'cache' is the place to hold vnodes for future use which may *not* >> come, hence vnodes held in namecache should be reclaimed in case of >> critical vnode shortage. Alfred> Are these changes planned for integration? Yes, but not very soon as there are a few kinds of works that should be done. One is that a directory vnode may be held as the working directory of a process, in which case we should not reclaim the directory vnode. Another is to determine how often namecache should be traversed to reclaim how many directory vnodes. At this moment, namecache is traversed for every 1,000 calls of getnewvnode(). If the following couple of inequalities satisfy, then up to 3,000 directory vnodes are attempted to be reclaimed: freevnodes < wantfreevnodes + 2 * 1000 (1) wantfreevnodes + 2 * 1000 < numvnodes * 2 (2) (1) means that we reclaim directory vnodes if the number of free vnodes are smaller than about 2,000. (2) is so that vnode reclaiming does not occur in the early stage of boot until the number of vnodes reaches around 2,000. Although I chose those parameters so that vnode reclaiming does not degrade the hit ratio of name lookup, they may not be optimum. Those parameters should be tunable via sysctl(2). Anyway, the patch can be found at: http://people.FreeBSD.org/~tanimura/patches/vnrecycle.diff -- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 13 9:38:32 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from search.sparks.net (search.sparks.net [208.5.188.60]) by hub.freebsd.org (Postfix) with ESMTP id EF8B437B505 for ; Fri, 13 Apr 2001 09:38:30 -0700 (PDT) (envelope-from dmiller@sparks.net) Received: by search.sparks.net (Postfix, from userid 100) id 05D2CDB24; Fri, 13 Apr 2001 12:38:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by search.sparks.net (Postfix) with ESMTP id E9588DB23 for ; Fri, 13 Apr 2001 12:38:21 -0400 (EDT) Date: Fri, 13 Apr 2001 12:38:21 -0400 (EDT) From: David Miller To: freebsd-hackers@freebsd.org Subject: [OT] parallel port for IO? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all;) Anyone know of a way to get a low cost port of some kind to to simple state change detection? The specific purpose is to time external events which are triggered by breaking an LED light beam. Millisecond resolution would be fine. I was thinking of sampling the parallel port repeatedly and looking for data lines to be high or low. Feasible? Thanks, --- David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 13 10:31:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 006C737B507 for ; Fri, 13 Apr 2001 10:31:16 -0700 (PDT) (envelope-from crossd@spigot.cs.rpi.edu) Received: from spigot.cs.rpi.edu (spigot.cs.rpi.edu [128.113.96.204]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id NAA07979 for ; Fri, 13 Apr 2001 13:31:14 -0400 (EDT) Message-Id: <200104131731.NAA07979@cs.rpi.edu> To: freebsd-hackers@freebsd.org Subject: ypserv (on -RC/-STABLE)... almost there Date: Fri, 13 Apr 2001 13:31:14 -0400 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have trace the problem in ypserv down to the RPC dispatch routines.. I am digging further and I hope to have it found and eliminated today (in time for -RELEASE ;) If anyone has any idea how it could be tripping up here, please let me know. My 2 guesses are a corrupted svc_callback entry (no idea how it is getting corrupted, yet.) or there is something walking on stuff within ypprog_1 or ypprog_2 (I don't know yet if the segfault is the (sc->dispatch) call in svc.c in the rpc library, or if it is within the function that sc->dispatch calls (the next seg-fault will let me know this.) -- David Cross | email: crossd@cs.rpi.edu Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 13 12:24:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from relayout1.micronpc.com (meihost.micronpc.com [209.19.139.2]) by hub.freebsd.org (Postfix) with ESMTP id 01DFE37B446 for ; Fri, 13 Apr 2001 12:24:08 -0700 (PDT) (envelope-from mpsimerson@hostpro.com) Received: from mei00wssout01.micron.com (mei00wssout01.micronpc.com [172.30.41.216]) by relayout1.micronpc.com (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP id NAA05542 for ; Fri, 13 Apr 2001 13:23:36 -0600 Received: from 172.30.41.146 by mei00wssout01.micron.com with ESMTP ( Tumbleweed MMS SMTP Relay(WSS) v4.5); Fri, 13 Apr 2001 13:23:36 -0600 X-Server-Uuid: 6b1d535a-5b27-11d3-bf09-00902786a6a3 Received: by imcout1.micronpc.com with Internet Mail Service ( 5.5.2650.21) id <26J7QK2L>; Fri, 13 Apr 2001 13:24:16 -0600 Message-ID: <8D18712B2604D411A6BB009027F6449801B4B5B6@0SEA01EXSRV1> From: "Matt Simerson" To: "'freebsd-hackers@freebsd.org'" Subject: Quota reporting is inaccurate. Date: Fri, 13 Apr 2001 13:23:23 -0600 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 X-WSS-ID: 16C98DB250197-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have an streaming server that does a mere three things in life. It accepts FTP connections from users with local accounts and streams the files back via Real streaming server or Darwin Streaming Server. That's it, other than some log file processing and backups, that's all this machine does. In the last 8 months of service, a few anomolies related to quotas have popped up. Every time it happens, the quota mechanism reports that the user is using more space than they really are. I've dug through the mailing list archives and found another user with this same problem so I'm going to add a little fuel that fire and hope a resolution to this can be found. On this machine all users get a fixed quota size which they are obliged not to exceed. Quota's are set up as follows: real1# more /etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/mlxd0s1b none swap sw 0 0 /dev/mlxd0s1a / ufs rw 1 1 /dev/mlxd1s1e /usr ufs rw,userquota 2 2 /dev/mlxd0s1e /var ufs rw 2 2 proc /proc procfs rw 0 0 Quotas are enabled at boot time: real1# grep quota /etc/rc.conf enable_quotas="YES" For the most part, quota's work just fine. I build this machine on FreeBSD 4.1.1-STABLE shortly after 4.1.1 was released. The server has been humming along, doing it's streaming thing quite nicely. It's only reboot in the last 8 months was last month when I upgraded from 4.1.1 to 4.2-STABLE (4.3-BETA) hoping for a fix to the quota problem. FTP connections are chrooted to the users home directory so the user cannot write files outside it. We can see how much space is in use as follows: real1# du -d1 ~dahl 190827 /usr/home/dahl So the user is only using 190MB of space on /usr. We can verify this by checking the entire /usr filesystem and verifying all results are in ~dahl which I have done as follows: real1# find /usr -user dahl So, the only files owned by dahl that exist live in his home dir as expected. Doing a long list on the files confirms the file sizes and du's count of 190MB: real1# ll ~dahl total 190826 -rw-r--r-- 1 dahl user 628 Mar 27 15:10 .cshrc -rw-r--r-- 1 dahl user 299 Mar 27 15:10 .login -rw-r--r-- 1 dahl user 160 Mar 27 15:10 .login_conf -rw------- 1 dahl user 371 Mar 27 15:10 .mail_aliases -rw-r--r-- 1 dahl user 331 Mar 27 15:10 .mailrc -rw-r--r-- 1 dahl user 722 Mar 27 15:10 .profile -rw------- 1 dahl user 276 Mar 27 15:10 .rhosts -rw-r--r-- 1 dahl user 852 Mar 27 15:10 .shrc -rwxr-xr-x 1 dahl user 108 Mar 27 15:10 .xinitrc -rwxr-xr-x 1 dahl user 108 Mar 27 15:10 .xsession -rw-r--r-- 1 dahl user 35826182 Apr 9 20:26 Mon040901.rm -rw-r--r-- 1 dahl user 47932775 Apr 9 12:03 Phish.rm -rw-r--r-- 1 dahl user 35451065 Apr 10 17:33 Tue041001.rm -rw-r--r-- 1 dahl user 37613531 Mar 30 17:40 best0f5.rm -rw-r--r-- 1 dahl user 38383851 Mar 30 08:17 bestof4.rm We verify our quota settings noting that quota's think that dahl is using 345MB when in reality it should be reporting 190MB: real1# quota dahl Disk quotas for user dahl (uid 4639): Filesystem blocks quota limit grace files quota limit grace /usr 345659 358400 358400 21 1000 2000 OK, so somehow our quota consistency got maligned. Running quotacheck should fix this right? So, we run quotacheck on our /usr filesystem: real1# quotacheck -v /usr *** Checking user quotas for /dev/mlxd1s1e (/usr) unknown uid: 1751 root fixed: blocks 2508870 -> 2508868 real fixed: blocks 197062 -> 197046 So, quotacheck doesn't discover or fix the discrepancy. :-( Any ideas why this behavior would occur? Better yet, any idea how to fix it? Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 13 13: 4:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from relayout1.micronpc.com (meihost.micronpc.com [209.19.139.2]) by hub.freebsd.org (Postfix) with ESMTP id 0C49437B507 for ; Fri, 13 Apr 2001 13:04:14 -0700 (PDT) (envelope-from mpsimerson@hostpro.com) Received: from mei00wssout01.micron.com (mei00wssout01.micronpc.com [172.30.41.216]) by relayout1.micronpc.com (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP id OAA06074; Fri, 13 Apr 2001 14:03:47 -0600 Received: from 172.30.41.146 by mei00wssout01.micron.com with ESMTP ( Tumbleweed MMS SMTP Relay(WSS) v4.5); Fri, 13 Apr 2001 14:03:47 -0600 X-Server-Uuid: 6b1d535a-5b27-11d3-bf09-00902786a6a3 Received: by imcout1.micronpc.com with Internet Mail Service ( 5.5.2650.21) id <26J7QK5G>; Fri, 13 Apr 2001 14:04:28 -0600 Message-ID: <8D18712B2604D411A6BB009027F6449801B4B5B9@0SEA01EXSRV1> From: "Matt Simerson" To: "'Ken Stox'" Cc: "'freebsd-hackers@freebsd.org'" Subject: RE: Quota reporting is inaccurate. Date: Fri, 13 Apr 2001 14:03:34 -0600 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 X-WSS-ID: 16C9842954480-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Actually, I believe it reports based upon the contents of the BLOCKSIZE environment variable which is 1k or 1024 bytes for the purposes of this discussion. In either case, you'll notice that the reporting shown below accurately shows that the users quota is very near the limit and the quota is set at 350MB. Interestingly enough, I added check_quotas="YES" to /etc/rc.conf and rebooted. That fixed that users quota problem. I'm not sure if it was the rebooting (and clearing the kernels idea of what the quota should be) or if running quotacheck in single user mode did it. I have to guess the former because quotacheck's results should not vary dependent on whether the machine is single user or not. Matt > -----Original Message----- > From: Ken Stox [mailto:stox@enteract.com] > Sent: Friday, April 13, 2001 12:40 PM > To: Matt Simerson > Subject: Re: Quota reporting is inaccurate. > > > > If memory serves correct, I think you will find quota reports 512byte > block, not 1k blocks. > > On Fri, 13 Apr 2001, Matt Simerson wrote: > > > I have an streaming server that does a mere three things in > life. It accepts > > FTP connections from users with local accounts and streams > the files back > > via Real streaming server or Darwin Streaming Server. > That's it, other than > > some log file processing and backups, that's all this machine does. > > > > In the last 8 months of service, a few anomolies related to > quotas have > > popped up. Every time it happens, the quota mechanism > reports that the user > > is using more space than they really are. I've dug through > the mailing list > > archives and found another user with this same problem so > I'm going to add a > > little fuel that fire and hope a resolution to this can be found. > > > > On this machine all users get a fixed quota size which they > are obliged not > > to exceed. Quota's are set up as follows: > > > > real1# more /etc/fstab > > # Device Mountpoint FStype Options > Dump > > Pass# > > /dev/mlxd0s1b none swap sw > 0 > > 0 > > /dev/mlxd0s1a / ufs rw > 1 > > 1 > > /dev/mlxd1s1e /usr ufs > rw,userquota 2 > > 2 > > /dev/mlxd0s1e /var ufs rw > 2 > > 2 > > proc /proc procfs rw > 0 > > 0 > > > > Quotas are enabled at boot time: > > > > real1# grep quota /etc/rc.conf > > enable_quotas="YES" > > > > For the most part, quota's work just fine. I build this > machine on FreeBSD > > 4.1.1-STABLE shortly after 4.1.1 was released. The server > has been humming > > along, doing it's streaming thing quite nicely. It's only > reboot in the last > > 8 months was last month when I upgraded from 4.1.1 to > 4.2-STABLE (4.3-BETA) > > hoping for a fix to the quota problem. FTP connections are > chrooted to the > > users home directory so the user cannot write files outside > it. We can see > > how much space is in use as follows: > > > > real1# du -d1 ~dahl > > 190827 /usr/home/dahl > > > > So the user is only using 190MB of space on /usr. We can > verify this by > > checking the entire /usr filesystem and verifying all > results are in ~dahl > > which I have done as follows: > > > > real1# find /usr -user dahl > > > > So, the only files owned by dahl that exist live in his home dir as > > expected. Doing a long list on the files confirms the file > sizes and du's > > count of 190MB: > > > > real1# ll ~dahl > > total 190826 > > -rw-r--r-- 1 dahl user 628 Mar 27 15:10 .cshrc > > -rw-r--r-- 1 dahl user 299 Mar 27 15:10 .login > > -rw-r--r-- 1 dahl user 160 Mar 27 15:10 .login_conf > > -rw------- 1 dahl user 371 Mar 27 15:10 .mail_aliases > > -rw-r--r-- 1 dahl user 331 Mar 27 15:10 .mailrc > > -rw-r--r-- 1 dahl user 722 Mar 27 15:10 .profile > > -rw------- 1 dahl user 276 Mar 27 15:10 .rhosts > > -rw-r--r-- 1 dahl user 852 Mar 27 15:10 .shrc > > -rwxr-xr-x 1 dahl user 108 Mar 27 15:10 .xinitrc > > -rwxr-xr-x 1 dahl user 108 Mar 27 15:10 .xsession > > -rw-r--r-- 1 dahl user 35826182 Apr 9 20:26 Mon040901.rm > > -rw-r--r-- 1 dahl user 47932775 Apr 9 12:03 Phish.rm > > -rw-r--r-- 1 dahl user 35451065 Apr 10 17:33 Tue041001.rm > > -rw-r--r-- 1 dahl user 37613531 Mar 30 17:40 best0f5.rm > > -rw-r--r-- 1 dahl user 38383851 Mar 30 08:17 bestof4.rm > > > > We verify our quota settings noting that quota's think that > dahl is using > > 345MB when in reality it should be reporting 190MB: > > > > real1# quota dahl > > Disk quotas for user dahl (uid 4639): > > Filesystem blocks quota limit grace files > quota limit > > grace > > /usr 345659 358400 358400 21 > 1000 2000 > > > > > > OK, so somehow our quota consistency got maligned. Running > quotacheck should > > fix this right? So, we run quotacheck on our /usr filesystem: > > > > real1# quotacheck -v /usr > > *** Checking user quotas for /dev/mlxd1s1e (/usr) > > unknown uid: 1751 > > root fixed: blocks 2508870 -> 2508868 > > real fixed: blocks 197062 -> 197046 > > > > So, quotacheck doesn't discover or fix the discrepancy. :-( > > > > Any ideas why this behavior would occur? Better yet, any > idea how to fix > > it? > > > > Matt > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 13 13:23:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.matriplex.com (ns1.matriplex.com [208.131.42.8]) by hub.freebsd.org (Postfix) with ESMTP id 8F78037B43F for ; Fri, 13 Apr 2001 13:23:43 -0700 (PDT) (envelope-from rh@matriplex.com) Received: from mail.matriplex.com (mail.matriplex.com [208.131.42.9]) by mail.matriplex.com (8.9.2/8.9.2) with ESMTP id NAA69036; Fri, 13 Apr 2001 13:23:26 -0700 (PDT) (envelope-from rh@matriplex.com) Date: Fri, 13 Apr 2001 13:23:26 -0700 (PDT) From: Richard Hodges To: Matt Simerson Cc: "'freebsd-hackers@freebsd.org'" Subject: RE: Quota reporting is inaccurate. In-Reply-To: <8D18712B2604D411A6BB009027F6449801B4B5B9@0SEA01EXSRV1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 13 Apr 2001, Matt Simerson wrote: > Actually, I believe it reports based upon the contents of the BLOCKSIZE > environment variable which is 1k or 1024 bytes for the purposes of this > discussion. In either case, you'll notice that the reporting shown below > accurately shows that the users quota is very near the limit and the quota > is set at 350MB. > > Interestingly enough, I added check_quotas="YES" to /etc/rc.conf and > rebooted. That fixed that users quota problem. I'm not sure if it was the > rebooting (and clearing the kernels idea of what the quota should be) or if > running quotacheck in single user mode did it. I have to guess the former > because quotacheck's results should not vary dependent on whether the > machine is single user or not. A while ago, I wanted to be sure that quotas were working and did some tests (on 3.4 release I think). In general, they worked as expected, except that when root changed a file's ownership, the quotas did not seem to reflect the change. I thought this was fixed in 4.x (when I did some more tests), but maybe this is still an issue? Are there file ownership changes going on? Another thought is that this user may have had files still open. Even if you "remove" a file, it really does not go away until the last open handle is closed. All the best, -Richard ------------------------------------------- Richard Hodges | Matriplex, inc. Product Manager | 769 Basque Way rh@matriplex.com | Carson City, NV 89706 775-886-6477 | www.matriplex.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 13 14:40:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from totem.fix.no (totem.fix.no [213.142.66.130]) by hub.freebsd.org (Postfix) with ESMTP id 02A1C37B507; Fri, 13 Apr 2001 14:40:06 -0700 (PDT) (envelope-from anders@totem.fix.no) Received: by totem.fix.no (Postfix, from userid 1000) id EC8963CC8; Fri, 13 Apr 2001 23:40:04 +0200 (CEST) Date: Fri, 13 Apr 2001 23:40:04 +0200 From: Anders Nordby To: alfred@freebsd.org Cc: freebsd-hackers@FreeBSD.ORG Subject: Recent RPC changes to -current Message-ID: <20010413234004.A73657@totem.fix.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 4.1.1-STABLE X-PGP-Key: http://anders.fix.no/pgp/ X-PGP-Key-FingerPrint: 1E0F C53C D8DF 6A8F EAAD 19C5 D12A BC9F 0083 5956 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, Are you going to bring in include files or something that defines such stuff as T_CLTS, FMNAMESZ etc.? In Solaris, this stuff can be found in /usr/include/sys/ files. Your removing of rpcgen -b as default prevents my port of drac (/usr/ports/mail/drac) from building in -current: cc -DSOCK_RPC -DFLOCK_LOCK -DGETHOST -DDASH_C -g -I/usr/local/include -DDBFILE=\"/usr/local/etc/dracd.db\" -DALFILE=\"/usr/local/etc/dracd.allow\" -c drac_svc.c drac_svc.c: In function `closedown': drac_svc.c:62: storage size of `tinfo' isn't known drac_svc.c:64: `T_CLTS' undeclared (first use in this function) drac_svc.c:64: (Each undeclared identifier is reported only once drac_svc.c:64: for each function it appears in.) drac_svc.c: In function `dracmain': drac_svc.c:139: `FMNAMESZ' undeclared (first use in this function) drac_svc.c:139: size of array `mname' has non-integer type drac_svc.c:141: `I_LOOK' undeclared (first use in this function) drac_svc.c:158: `T_DATAXFER' undeclared (first use in this function) drac_svc.c:161: `I_POP' undeclared (first use in this function) drac_svc.c:161: `I_PUSH' undeclared (first use in this function) *** Error code 1 And I didn't find a solution yet, except for explicitly using rpcgen -b of course. Cheers, -- Anders. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 13 14:49:10 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from relayout1.micronpc.com (meihost.micronpc.com [209.19.139.2]) by hub.freebsd.org (Postfix) with ESMTP id D67AF37B422 for ; Fri, 13 Apr 2001 14:49:06 -0700 (PDT) (envelope-from mpsimerson@hostpro.com) Received: from mei00wssout01.micron.com (mei00wssout01.micronpc.com [172.30.41.216]) by relayout1.micronpc.com (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP id PAA07665 for ; Fri, 13 Apr 2001 15:48:41 -0600 Received: from 172.30.41.146 by mei00wssout01.micron.com with ESMTP ( Tumbleweed MMS SMTP Relay(WSS) v4.5); Fri, 13 Apr 2001 15:48:41 -0600 X-Server-Uuid: 6b1d535a-5b27-11d3-bf09-00902786a6a3 Received: by imcout1.micronpc.com with Internet Mail Service ( 5.5.2650.21) id <26J7QMX7>; Fri, 13 Apr 2001 15:49:21 -0600 Message-ID: <8D18712B2604D411A6BB009027F6449801B4B5BF@0SEA01EXSRV1> From: "Matt Simerson" To: "'freebsd-hackers@freebsd.org'" Subject: RE: Quota reporting is inaccurate. Date: Fri, 13 Apr 2001 15:48:28 -0600 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 X-WSS-ID: 16C9ABB3894743-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > -----Original Message----- > From: Richard Hodges [mailto:rh@matriplex.com] > Sent: Friday, April 13, 2001 1:23 PM > To: Matt Simerson > Cc: 'freebsd-hackers@freebsd.org' > Subject: RE: Quota reporting is inaccurate. > > > On Fri, 13 Apr 2001, Matt Simerson wrote: > > > Interestingly enough, I added check_quotas="YES" to /etc/rc.conf and > > rebooted. That fixed that users quota problem. I'm not sure > if it was the > > rebooting (and clearing the kernels idea of what the quota > should be) or if > > running quotacheck in single user mode did it. I have to > guess the former > > because quotacheck's results should not vary dependent on > whether the > > machine is single user or not. > > A while ago, I wanted to be sure that quotas were working and did some > tests (on 3.4 release I think). In general, they worked as expected, > except that when root changed a file's ownership, the quotas did not > seem to reflect the change. > > I thought this was fixed in 4.x (when I did some more tests), > but maybe this is still an issue? Are there file ownership changes going on? There shouldn't be anything like that happening. Every username is an unique user on the box and the only poeple with the ability to interactively login are employees are I log everything they do. > Another thought is that this user may have had files still open. Even > if you "remove" a file, it really does not go away until the last open > handle is closed. That seems like the most likely possibility. However, only one daemon can add or delete files and that's FreeBSD's built in FTP daemon. If the deamon isn't running (and it wasn't) then the file shouldn't be open (in theory). I just installed lsof and we'll see if that doesn't reveal anything next time I see this crop up. Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 13 14:57:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 9418437B423 for ; Fri, 13 Apr 2001 14:57:25 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3DLvNc26300; Fri, 13 Apr 2001 14:57:23 -0700 (PDT) Date: Fri, 13 Apr 2001 14:57:23 -0700 From: Alfred Perlstein To: Anders Nordby Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Recent RPC changes to -current Message-ID: <20010413145723.Q976@fw.wintelcom.net> References: <20010413234004.A73657@totem.fix.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010413234004.A73657@totem.fix.no>; from anders@fix.no on Fri, Apr 13, 2001 at 11:40:04PM +0200 X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Anders Nordby [010413 14:40] wrote: > Hello, > > Are you going to bring in include files or something that defines such > stuff as T_CLTS, FMNAMESZ etc.? In Solaris, this stuff can be found in > /usr/include/sys/ files. Your removing of rpcgen -b as default prevents my > port of drac (/usr/ports/mail/drac) from building in -current: NO. :) I've forwarded your mail off to iedowse@freebsd.org and Martin Blapp who should be able fix it. > > cc -DSOCK_RPC -DFLOCK_LOCK -DGETHOST -DDASH_C -g -I/usr/local/include > -DDBFILE=\"/usr/local/etc/dracd.db\" -DALFILE=\"/usr/local/etc/dracd.allow\" > -c drac_svc.c > drac_svc.c: In function `closedown': > drac_svc.c:62: storage size of `tinfo' isn't known > drac_svc.c:64: `T_CLTS' undeclared (first use in this function) > drac_svc.c:64: (Each undeclared identifier is reported only once > drac_svc.c:64: for each function it appears in.) > drac_svc.c: In function `dracmain': > drac_svc.c:139: `FMNAMESZ' undeclared (first use in this function) > drac_svc.c:139: size of array `mname' has non-integer type > drac_svc.c:141: `I_LOOK' undeclared (first use in this function) > drac_svc.c:158: `T_DATAXFER' undeclared (first use in this function) > drac_svc.c:161: `I_POP' undeclared (first use in this function) > drac_svc.c:161: `I_PUSH' undeclared (first use in this function) > *** Error code 1 > > And I didn't find a solution yet, except for explicitly using rpcgen -b of > course. > > Cheers, > > -- > Anders. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Represent yourself, show up at BABUG http://www.babug.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 13 18:13:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.javanet.com (mail1.javanet.com [205.219.162.10]) by hub.freebsd.org (Postfix) with ESMTP id B9FEE37B449 for ; Fri, 13 Apr 2001 18:13:40 -0700 (PDT) (envelope-from kaworu@sektor7.ath.cx) Received: from wintermute.sekt7.org (209-6-248-6.c3-0.lex-ubr1.sbo-lex.ma.cable.rcn.com [209.6.248.6]) by mail1.javanet.com (8.9.3/8.9.2) with ESMTP id VAA04346 for ; Fri, 13 Apr 2001 21:13:44 -0400 (EDT) Date: Fri, 13 Apr 2001 21:17:13 -0400 (EDT) From: Evan S X-Sender: kaworu@wintermute.sekt7 To: freebsd-hackers@freebsd.org Subject: question on kvm_getprocs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I am writing a program called jailstat, which goes through the proc structure, checks if p_prison is true, if it is, prints out p_prison->pr_host. I have it working so it says, "jailed process", and prints out it's UID. But, when I try to make it print the hostname, this is what happens. Here's a snippet of code: if ((kinfo = malloc(nentries * sizeof(*kinfo))) == NULL) err(1, NULL); for (i = nentries; --i >= 0; ++proc_list) { (&kinfo[i])->ki_p = proc_list; if (KI_PROC(&kinfo[i])->p_prison) { printf("Jailed Process\n"); printf("%s\n", KI_PROC(&kinfo[i])->p_prison->pr_host); } } KI_PROC is just a macro that is #define KI_PROC(ki) (&(ki)->ki_p->kp_proc) [teqnix](~/work/c/getprocs)%gcc -g -lkvm getprocs.c -o getprocs getprocs.c: In function `main': getprocs.c:87: dereferencing pointer to incomplete type If anyone could give a little help. Thanks a lot. :-) Evan Sarmiento (kaworu@sektor7.ath.cx) http://sekt7.org/es -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (SunOS) Comment: Made with pgp4pine 1.75-6 iEYEARECAAYFAjrXpR8ACgkQa7CFsJ0L22wnawCgpVWLMcqBegbb5opBR2Hx8esV KJMAoJlZ1a/BsqqbPh8TxiTISPyN85fA =SaP9 -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 13 18:32:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 7462A37B506 for ; Fri, 13 Apr 2001 18:32:19 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: from spike.unixfreak.org (spike [63.198.170.139]) by bazooka.unixfreak.org (Postfix) with ESMTP id 93BED3E25; Fri, 13 Apr 2001 18:32:18 -0700 (PDT) To: Evan S Cc: freebsd-hackers@freebsd.org Subject: Re: question on kvm_getprocs In-Reply-To: ; from kaworu@sektor7.ath.cx on "Fri, 13 Apr 2001 21:17:13 -0400 (EDT)" Date: Fri, 13 Apr 2001 18:32:18 -0700 From: Dima Dorfman Message-Id: <20010414013218.93BED3E25@bazooka.unixfreak.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Evan S writes: > if ((kinfo = malloc(nentries * sizeof(*kinfo))) == NULL) > err(1, NULL); > for (i = nentries; --i >= 0; ++proc_list) { > (&kinfo[i])->ki_p = proc_list; > if (KI_PROC(&kinfo[i])->p_prison) > { > printf("Jailed Process\n"); > printf("%s\n", > > KI_PROC(&kinfo[i])->p_prison->pr_host); > } > } > > KI_PROC is just a macro that is > #define KI_PROC(ki) (&(ki)->ki_p->kp_proc) > > [teqnix](~/work/c/getprocs)%gcc -g -lkvm getprocs.c -o getprocs > getprocs.c: In function `main': > getprocs.c:87: dereferencing pointer to incomplete type pr_host is a member of struct prison, which is a kernel structure. It's under #ifdef _KERNEL, which is why you don't have a definition for it. I'm not quite sure where you're getting your process list from, but I think that p_prison is a kernel pointer in your context. Obviously, trying to follow that from the userland won't do what you want. :-) Then again, I could be wrong. If you want, take the definition of struct prison from /usr/include/sys/jail.h and paste it into your code. That will get rid of the warning. If your program seg faults when you try to run it, you'll know I was right. Regards, Dima Dorfman dima@unixfreak.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 13 18:48:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from slutpuppy.org (sparky.slutpuppy.org [64.48.179.179]) by hub.freebsd.org (Postfix) with ESMTP id 6472C37B50C for ; Fri, 13 Apr 2001 18:48:41 -0700 (PDT) (envelope-from partsman@liquidunix.org) Received: from localhost (partsman@localhost) by slutpuppy.org (8.11.3/8.10.0) with ESMTP id f3E1mU600836 for ; Fri, 13 Apr 2001 20:48:30 -0500 (CDT) Date: Fri, 13 Apr 2001 20:48:29 -0500 (CDT) From: John Hildreth X-X-Sender: Cc: Subject: SIIG 360P / SC PS2012 SCSI Card In-Reply-To: <20010414013218.93BED3E25@bazooka.unixfreak.org> Message-ID: SPARKY: SLUTPUPPY.ORG Clinton: "But I didnt inhale" Got: Milk? MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am wondering if theres antything in -stable that supports this card. from what I can find it uses the ini9100 chipset, and I cant find anything on the HW compat list about it. any help or insight would be appreciated John Hildreth MMPS Engineer Allegiance Telecom partsman@liquidunix.org Office: 469-259-2612 Cell: 214-914-3112 It has been said: > Evan S writes: > > if ((kinfo = malloc(nentries * sizeof(*kinfo))) == NULL) > > err(1, NULL); > > for (i = nentries; --i >= 0; ++proc_list) { > > (&kinfo[i])->ki_p = proc_list; > > if (KI_PROC(&kinfo[i])->p_prison) > > { > > printf("Jailed Process\n"); > > printf("%s\n", > > > > KI_PROC(&kinfo[i])->p_prison->pr_host); > > } > > } > > > > KI_PROC is just a macro that is > > #define KI_PROC(ki) (&(ki)->ki_p->kp_proc) > > > > [teqnix](~/work/c/getprocs)%gcc -g -lkvm getprocs.c -o getprocs > > getprocs.c: In function `main': > > getprocs.c:87: dereferencing pointer to incomplete type > > pr_host is a member of struct prison, which is a kernel structure. > It's under #ifdef _KERNEL, which is why you don't have a definition > for it. I'm not quite sure where you're getting your process list > from, but I think that p_prison is a kernel pointer in your context. > Obviously, trying to follow that from the userland won't do what you > want. :-) > > Then again, I could be wrong. If you want, take the definition of > struct prison from /usr/include/sys/jail.h and paste it into your > code. That will get rid of the warning. If your program seg faults > when you try to run it, you'll know I was right. > > Regards, > > Dima Dorfman > dima@unixfreak.org > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 14 5:37:48 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 99EA837B505 for ; Sat, 14 Apr 2001 05:37:44 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 7308 invoked by uid 1000); 14 Apr 2001 09:49:37 -0000 Date: Sat, 14 Apr 2001 12:49:37 +0300 From: Peter Pentchev To: Matt Simerson Cc: "'freebsd-hackers@freebsd.org'" Subject: Re: Quota reporting is inaccurate. Message-ID: <20010414124937.C5504@ringworld.oblivion.bg> Mail-Followup-To: Matt Simerson , "'freebsd-hackers@freebsd.org'" References: <8D18712B2604D411A6BB009027F6449801B4B5BF@0SEA01EXSRV1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <8D18712B2604D411A6BB009027F6449801B4B5BF@0SEA01EXSRV1>; from mpsimerson@hostpro.com on Fri, Apr 13, 2001 at 03:48:28PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Apr 13, 2001 at 03:48:28PM -0600, Matt Simerson wrote: > > Another thought is that this user may have had files still open. Even > > if you "remove" a file, it really does not go away until the last open > > handle is closed. > > That seems like the most likely possibility. However, only one daemon can > add or delete files and that's FreeBSD's built in FTP daemon. If the deamon > isn't running (and it wasn't) then the file shouldn't be open (in theory). I > just installed lsof and we'll see if that doesn't reveal anything next time > I see this crop up. If the streaming is done by something other than the FTP daemon, then the file *can* still be open, if someone was listening to it at the time the user deleted it via FTP. G'luck, Peter -- This sentence would be seven words long if it were six words shorter. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 14 5:48:52 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by hub.freebsd.org (Postfix) with ESMTP id 0CE1F37B617; Sat, 14 Apr 2001 05:48:48 -0700 (PDT) (envelope-from mb@imp.ch) Received: from harem (harem.imp.ch [157.161.4.8]) by mail.imp.ch (8.11.1/8.11.1) with ESMTP id f3ECma125258; Sat, 14 Apr 2001 14:48:37 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Sat, 14 Apr 2001 14:48:36 +0200 From: Martin Blapp To: Anders Nordby Cc: iedowse@freebsd.org, rwatson@freebsd.org, tmm@freebsd.org, alfred@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Recent RPC changes to -current In-Reply-To: <20010413145645.P976@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Can you check if this solves the drac problem in CURRENT ? Does drac work the way it should ? There were some flags actived in rpcgen, which shouldn't have been. I also modified your port a bit to use tirpc code and to not include netdir.h http://home.teleport.ch/freebsd/rpcgen.diff http://home.teleport.ch/freebsd/drac.diff Martin Martin Blapp, mb@imp.ch ------------------------------------------------ Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 79 370 26 05, Fax: +41 61 826 93 01 ------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 14 6:49:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by hub.freebsd.org (Postfix) with ESMTP id 9CDBF37B50D for ; Sat, 14 Apr 2001 06:49:17 -0700 (PDT) (envelope-from mb@imp.ch) Received: from harem (harem.imp.ch [157.161.4.8]) by mail.imp.ch (8.11.1/8.11.1) with ESMTP id f3EDnD126807; Sat, 14 Apr 2001 15:49:13 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Sat, 14 Apr 2001 15:49:13 +0200 From: Martin Blapp To: Anders Nordby Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Recent RPC changes to -current In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Anders, As I have seen, drac can only handle IPv4 requests at the moment. If you do like to see IPv6 support, I can make a patch for you. We can now support Ipv6 with rpc ports, since tirpc supports ipv6 also. 900101 1 udp6 ::ffff:0.0.0.0.3.225 - superuser 900101 1 tcp6 ::ffff:0.0.0.0.2.197 - superuser 900101 1 udp 0.0.0.0.3.224 - superuser 900101 1 tcp 0.0.0.0.2.196 - superuser Martin Martin Blapp, mb@imp.ch ------------------------------------------------ Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 79 370 26 05, Fax: +41 61 826 93 01 ------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 14 7:34:36 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.28]) by hub.freebsd.org (Postfix) with ESMTP id 3F3B737B42C for ; Sat, 14 Apr 2001 07:34:34 -0700 (PDT) (envelope-from fullermd@futuresouth.com) Received: (from fullermd@localhost) by shell.futuresouth.com (8.11.1/8.11.1) id f3EEYQq23826; Sat, 14 Apr 2001 09:34:26 -0500 (CDT) Date: Sat, 14 Apr 2001 09:34:26 -0500 From: "Matthew D. Fuller" To: Matt Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance Message-ID: <20010414093426.B4438@futuresouth.com> References: <59487.987108936@critter> <200104122124.f3CLOaq25845@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104122124.f3CLOaq25845@earth.backplane.com>; from dillon@earth.backplane.com on Thu, Apr 12, 2001 at 02:24:36PM -0700 X-OS: FreeBSD Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Apr 12, 2001 at 02:24:36PM -0700, a little birdie told me that Matt Dillon remarked > > Without vmiodirenable turned on, any directory exceeding > vfs.maxmallocbufspace becomes extremely expensive to work with > O(N * diskIO). With vmiodirenable turned on huge directories > are O(N), but have a better chance of being in the VM page cache > so cost proportionally less even though they don't do any > better on a relative scale. Speaking of vmiodirenable, what are the issues with it that it's not enabled by default? ISTR that it's been in a while, and most people pointed at it have reported success with it, and it seems to have solved problems here and there for a number of people. What's keeping it from the general case? -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Unix Systems Administrator | fullermd@futuresouth.com Specializing in FreeBSD | http://www.over-yonder.net/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 14 7:42:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 6E1A837B50D for ; Sat, 14 Apr 2001 07:42:08 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 8437 invoked by uid 1000); 14 Apr 2001 14:40:40 -0000 Date: Sat, 14 Apr 2001 17:40:40 +0300 From: Peter Pentchev To: "Matthew D. Fuller" Cc: Matt Dillon , freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance Message-ID: <20010414174040.C481@ringworld.oblivion.bg> Mail-Followup-To: "Matthew D. Fuller" , Matt Dillon , freebsd-hackers@FreeBSD.ORG References: <59487.987108936@critter> <200104122124.f3CLOaq25845@earth.backplane.com> <20010414093426.B4438@futuresouth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010414093426.B4438@futuresouth.com>; from fullermd@futuresouth.com on Sat, Apr 14, 2001 at 09:34:26AM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Apr 14, 2001 at 09:34:26AM -0500, Matthew D. Fuller wrote: > On Thu, Apr 12, 2001 at 02:24:36PM -0700, a little birdie told me > that Matt Dillon remarked > > > > Without vmiodirenable turned on, any directory exceeding > > vfs.maxmallocbufspace becomes extremely expensive to work with > > O(N * diskIO). With vmiodirenable turned on huge directories > > are O(N), but have a better chance of being in the VM page cache > > so cost proportionally less even though they don't do any > > better on a relative scale. > > Speaking of vmiodirenable, what are the issues with it that it's not > enabled by default? ISTR that it's been in a while, and most people > pointed at it have reported success with it, and it seems to have solved > problems here and there for a number of people. What's keeping it from > the general case? Attached is a message from Matt Dillon from an earlier -hackers discussion. G'luck, Peter -- The rest of this sentence is written in Thailand, on From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 23 02:15:39 2001 Date: Thu, 22 Mar 2001 16:14:11 -0800 (PST) From: Matt Dillon Message-Id: <200103230014.f2N0EBC61507@earth.backplane.com> To: "Michael C . Wu" Cc: fs@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: tuning a VERY heavily (30.0) loaded s cerver :(Why is vfs.vmiodirenable=1 not enabled by default?) : The only reason it isn't enabled by default is some unresolved filesystem corruption that occurs very rarely (with or without it) that Kirk and I are still trying to nail down. I want to get that figured out first. It is true that some people have brought up memory use issues, but I don't consider memory use to really be that much of an issue. This is a cache, after all, so the blocks can be reused at just about any time. And directory blocks do not get cached well at all with vmiodirenable turned off. So the net result should be an increase in performance even on low-memory boxes. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 14 10:22:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id E7E1837B5AF for ; Sat, 14 Apr 2001 10:22:09 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3EHLIr65933; Sat, 14 Apr 2001 10:21:18 -0700 (PDT) (envelope-from dillon) Date: Sat, 14 Apr 2001 10:21:18 -0700 (PDT) From: Matt Dillon Message-Id: <200104141721.f3EHLIr65933@earth.backplane.com> To: "Matthew D. Fuller" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance References: <59487.987108936@critter> <200104122124.f3CLOaq25845@earth.backplane.com> <20010414093426.B4438@futuresouth.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Speaking of vmiodirenable, what are the issues with it that it's not :enabled by default? ISTR that it's been in a while, and most people :pointed at it have reported success with it, and it seems to have solved :problems here and there for a number of people. What's keeping it from :the general case? : :-- :Matthew Fuller (MF4839) | fullermd@over-yonder.net I'll probably turn it on after the 4.3 release. Insofar as Kirk and I can tell there are no (hah!) filesystem corruption bugs left in the filesystem or VM code. I am guessing that what corruption still occurs occassionally is either due to something elsewhere in the kernel, or motherboard issues (e.g. like the VIA chipset IDE DMA corruption bug). I have just four words to say about IDE DMA: It's a f**ked standard. Neither Kirk nor I have been able to reproduce reported problems at all, but with help from others we have fixed a number of bugs which seem to have had a positive effect on Yahoo's test machines. At the moment one of Yahoo's 8 IDE test systems may crash once after a few hours, but then after reboot will never crash again. This hopefully means that fsck is fixing corruption generated from earlier buggy kernels that is caught later on. I've been exchanging email with three other people with corruption issues. One turned out to be hardware (fsck after newfs was failing, so obviously not a filesystem issue!), another is indeterminant, the third was working fine until late February and then new kernels started to result in corruption (while old kernels still worked) and he is now trying to narrow down the date range where the problem was introduced. Either way it should be fairly obvious if turning on vmiodirenable makes it worse or not. My guess is: not, and it's just my paranoia that is holding up turning on vmiodirenable. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 14 16:52:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by hub.freebsd.org (Postfix) with ESMTP id 991EB37B424 for ; Sat, 14 Apr 2001 16:52:56 -0700 (PDT) (envelope-from sven.huster@mailsurf.com) Received: from fwdtmp0.sul.t-online.com by mailout05.sul.t-online.com with smtp id 14oZqZ-0001jI-01; Sun, 15 Apr 2001 01:52:55 +0200 Received: from venus.mailsurf.com (320051988339-0001@[62.158.240.16]) by fmrl00.sul.t-online.com with esmtp id 14oZqW-0nqniaC; Sun, 15 Apr 2001 01:52:52 +0200 Message-Id: <5.0.2.1.0.20010415015212.022f55f8@mx01.mailsurf.com> X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sun, 15 Apr 2001 01:53:23 +0200 To: freebsd-hackers@freebsd.org From: Sven Huster Subject: Fwd: file cache (on nfs) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Sender: 320051988339-0001@t-dialin.net Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sorry, posted it to -questions and -stable and no answer yet. Maybe someone of you can help me Hi there, >can someone tell me how/if file caching is done on freebsd over nfs? >are the parameters to modify the behaviour (e.g. memory usage)? > >are there parameters for "normal" local disk cache also? > >thanks >regards Sven Huster Senior IT Systems Administrator *BSD, Linux, Solaris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 14 17: 8:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from et-gw.etinc.com (et-gw.etinc.com [207.252.1.2]) by hub.freebsd.org (Postfix) with ESMTP id 38D0137B424 for ; Sat, 14 Apr 2001 17:08:47 -0700 (PDT) (envelope-from dennis@etinc.com) Received: from dbsys.etinc.com (dbsys.etinc.com [207.252.1.18]) by et-gw.etinc.com (8.9.3/8.9.3) with ESMTP id UAA00508 for ; Sat, 14 Apr 2001 20:08:56 GMT (envelope-from dennis@etinc.com) Message-Id: <5.0.0.25.0.20010414192404.01ec0dd0@mail.etinc.com> X-Sender: dennis@mail.etinc.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 14 Apr 2001 19:27:21 -0400 To: hackers@FreeBSD.ORG From: Dennis Subject: stupid pet tricks (using ifconfig) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wierdness in 4.2. Scenario: interface fxp0 has address 100.1.1.1. Use it with this address for awhile. decide to change it to 100.1.1.5. do: ifconfig fxp0 delete 100.1.1.1 ifconfig fxp0 100.1.1.5 netmask 255.255.255.0 viewing ifconfig shows the new address. HOWEVER, pinging 100.1.1.99, the freebsd machine sends out 100.1.1.1, the OLD address. Is this cached/saved somewhere and not getting cleaned up? Dennis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 14 17:54:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id 8216E37B50C for ; Sat, 14 Apr 2001 17:54:18 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id CAA00221; Sun, 15 Apr 2001 02:52:52 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200104150052.CAA00221@info.iet.unipi.it> Subject: Re: stupid pet tricks (using ifconfig) In-Reply-To: <5.0.0.25.0.20010414192404.01ec0dd0@mail.etinc.com> from Dennis at "Apr 14, 2001 07:27:21 pm" To: Dennis Date: Sun, 15 Apr 2001 02:52:52 +0200 (CEST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > viewing ifconfig shows the new address. HOWEVER, pinging 100.1.1.99, the > freebsd machine sends out 100.1.1.1, the OLD address. > > Is this cached/saved somewhere and not getting cleaned up? in the routing table, apparently. If you do a "route -n get" for the destination address you see the old one. Manually flushing the relevant entries in the routing table does the job (yes it is a bug, it should happen automatically, and it is not 4.2 specific, it has been there forever) cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 14 19:50: 7 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id EE19B37B443; Sat, 14 Apr 2001 19:50:03 -0700 (PDT) (envelope-from DougB@DougBarton.net) Received: from DougBarton.net (master [10.0.0.2]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id TAA34200; Sat, 14 Apr 2001 19:50:01 -0700 (PDT) (envelope-from DougB@DougBarton.net) Message-ID: <3AD90C59.53E7DB55@DougBarton.net> Date: Sat, 14 Apr 2001 19:50:01 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Bakul Shah Cc: Robert Watson , r.hyunseog@ieee.org, hackers@FreeBSD.ORG Subject: Re: Interesting article. References: <200104101733.NAA09610@renown.cnchost.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bakul Shah wrote: > > >From the top level page I read hotmail handles 550,000 change > requests a day. Later in the article they say they have a > 5000 server farm. That translates to 110 change requests a > day on average per server. If the peak rate is 10 times the > average, that is still only about 1100 requests/server/day or > about 78 seconds on average. This rate seems quite low even > when you account for multiple web page servings per change > request.... Am I missing something obvious? You neglected to deduct the number of servers that are down/rebooting from the 5k. :) http://www.microsoft.com/backstage/column_T2_1.htm You just can't make this stuff up.... Doug -- Perhaps the greatest damage the American system of education has done to its children is to teach them that their opinions are relevant simply because they are their opinions. Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message