From owner-freebsd-arch Sun Dec 2 2:23:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id B9A5337B405; Sun, 2 Dec 2001 02:23:33 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB2ANMi91290; Sun, 2 Dec 2001 02:23:22 -0800 (PST) (envelope-from dillon) Date: Sun, 2 Dec 2001 02:23:22 -0800 (PST) From: Matthew Dillon Message-Id: <200112021023.fB2ANMi91290@apollo.backplane.com> To: Garance A Drosihn Cc: Robert Watson , arch@FreeBSD.ORG Subject: Re: Enabling Softupdates in default install on -CURRENT References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :At 11:27 PM -0500 12/1/01, Robert Watson wrote: :>I'm beginning to wonder if it isn't time to switch sysinstall to start :>configuring softupdates "by default" for file systems at install-time. :>We currently allow it to be selected, but don't enable it by default. :>I would propose it be turned on by default for all non-root file :>systems, or some other similar rule (file systems <64MB, ..). : :I expect it would be best to have it default 'off' for /, because the :user can get into strange-seeming failures when installing a new kernel. :I do like the idea of it being on for most other filesystems. : :I don't have much of an opinion as to whether it should also default :to off for other "small" file systems. I agree. / is still a problem - I have softupdates enabled on my 128M / partitions and if I 'make install' a kernel twice in a row the filesystem runs out of space and the second install fails. But that's the only time I've ever managed to run a softupdates filesystem out of space. If we incorporated a couple of 'sync's (like eight of them) at the beginning of a kernel or world install target it would probably be safe enough. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 2 4:47:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id E42F537B419 for ; Sun, 2 Dec 2001 04:47:16 -0800 (PST) Received: (from ache@localhost) by nagual.pp.ru (8.11.6/8.11.6) id fB2Cl2V60864; Sun, 2 Dec 2001 15:47:02 +0300 (MSK) (envelope-from ache) Date: Sun, 2 Dec 2001 15:47:02 +0300 From: "Andrey A. Chernov" To: Mark Murray Cc: arch@FreeBSD.ORG Subject: Re: BSD sort vs GNU sort. Message-ID: <20011202124701.GA60816@nagual.pp.ru> References: <20011201011438.GE28257@nagual.pp.ru> <200112011008.fB1A8s028305@grimreaper.grondar.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200112011008.fB1A8s028305@grimreaper.grondar.org> User-Agent: Mutt/1.3.23.2i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Dec 01, 2001 at 10:08:53 +0000, Mark Murray wrote: > > On Fri, Nov 30, 2001 at 16:22:21 +0000, Mark Murray wrote: > > > > > > Do you think you would be able to engineer proper i18n support into > > > this BSD sort if I were to import it? > > > > Where I can look at the its latest sources? NetBSD? > > Yes. I can get a copy somewhere if you need me to. Just check it. BSD sort provide byte by byte sorting, so will understand only one byte collation sequences, if collation support will be added there. GNU sort is a little different: sometimes it compares parts of string, not bytes, so it will lead to longer collation sequences understanding. It is still possible to add one byte collation support to BSD sort, also it will be harder than adding it to GNU sort, because whole collation table must be builded first, before runtime comparison. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 2 5: 0:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id AE36F37B41D for ; Sun, 2 Dec 2001 05:00:16 -0800 (PST) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.11.6/8.11.6) with UUCP id fB2D0Cf61959; Sun, 2 Dec 2001 13:00:12 GMT (envelope-from mark@grondar.za) Received: from grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.org (8.11.6/8.11.6) with ESMTP id fB2D06036554; Sun, 2 Dec 2001 13:00:06 GMT (envelope-from mark@grondar.za) Message-Id: <200112021300.fB2D06036554@grimreaper.grondar.org> To: "Andrey A. Chernov" Cc: arch@FreeBSD.ORG Subject: Re: BSD sort vs GNU sort. References: <20011202124701.GA60816@nagual.pp.ru> In-Reply-To: <20011202124701.GA60816@nagual.pp.ru> ; from "Andrey A. Chernov" "Sun, 02 Dec 2001 15:47:02 +0300." Date: Sun, 02 Dec 2001 13:00:06 +0000 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Just check it. Cool! > BSD sort provide byte by byte sorting, so will understand only one byte > collation sequences, if collation support will be added there. GNU sort is > a little different: sometimes it compares parts of string, not bytes, so > it will lead to longer collation sequences understanding. > > It is still possible to add one byte collation support to BSD sort, also > it will be harder than adding it to GNU sort, because whole collation > table must be builded first, before runtime comparison. So, can you do it? And if so, _will_ you do it? :-) M -- o Mark Murray \_ FreeBSD Services Limited O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 2 5: 8:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id 3ED5737B417 for ; Sun, 2 Dec 2001 05:08:08 -0800 (PST) Received: (from ache@localhost) by nagual.pp.ru (8.11.6/8.11.6) id fB2D85161095; Sun, 2 Dec 2001 16:08:05 +0300 (MSK) (envelope-from ache) Date: Sun, 2 Dec 2001 16:08:04 +0300 From: "Andrey A. Chernov" To: Mark Murray Cc: arch@FreeBSD.ORG Subject: Re: BSD sort vs GNU sort. Message-ID: <20011202130804.GA61024@nagual.pp.ru> References: <20011202124701.GA60816@nagual.pp.ru> <200112021300.fB2D06036554@grimreaper.grondar.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200112021300.fB2D06036554@grimreaper.grondar.org> User-Agent: Mutt/1.3.23.2i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Dec 02, 2001 at 13:00:06 +0000, Mark Murray wrote: > > It is still possible to add one byte collation support to BSD sort, also > > it will be harder than adding it to GNU sort, because whole collation > > table must be builded first, before runtime comparison. > > So, can you do it? > > And if so, _will_ you do it? :-) Yes, but it may takes some amount of time, it will be not easy patch as for GNU sort. BTW, what exactly is urgent in sort replacement idea? As I see by first look, BSD sort as designed will be somewhat faster, but needs lots of temporary files comparing to GNU sort. The next thing we need to check _before_ switch efforts is its POSIX conformance. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 2 9:57:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id 8948837B416; Sun, 2 Dec 2001 09:57:43 -0800 (PST) Received: from winston.freebsd.org (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id fB2Hvbq11360; Sun, 2 Dec 2001 09:57:37 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: Robert Watson Cc: arch@FreeBSD.ORG Subject: Re: Enabling Softupdates in default install on -CURRENT In-Reply-To: Message from Robert Watson of "Sat, 01 Dec 2001 23:27:30 EST." Date: Sun, 02 Dec 2001 09:57:37 -0800 Message-ID: <11356.1007315857@winston.freebsd.org> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sounds reasonable to me. I think it's been well-tested enough by now. > I'm beginning to wonder if it isn't time to switch sysinstall to start > configuring softupdates "by default" for file systems at install-time. We > currently allow it to be selected, but don't enable it by default. I > would propose it be turned on by default for all non-root file systems, or > some other similar rule (file systems <64MB, ..). Given that this is the > primary recommendation made for system performance tuning, and not only > addresses performance but improved reliability, it seems to me that this > would be a sensible change to introduce at some useful breaking point, and > 5.0 provides a good opportunity to do that. > > Any objections? > > 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-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 2 11:26:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 0A86837B416 for ; Sun, 2 Dec 2001 11:26:39 -0800 (PST) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.11.6/8.11.6) with UUCP id fB2JQJr02842; Sun, 2 Dec 2001 19:26:19 GMT (envelope-from mark@grondar.za) Received: from grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.org (8.11.6/8.11.6) with ESMTP id fB2Dhh036928; Sun, 2 Dec 2001 13:43:43 GMT (envelope-from mark@grondar.za) Message-Id: <200112021343.fB2Dhh036928@grimreaper.grondar.org> To: "Andrey A. Chernov" Cc: arch@FreeBSD.ORG Subject: Re: BSD sort vs GNU sort. References: <20011202130804.GA61024@nagual.pp.ru> In-Reply-To: <20011202130804.GA61024@nagual.pp.ru> ; from "Andrey A. Chernov" "Sun, 02 Dec 2001 16:08:04 +0300." Date: Sun, 02 Dec 2001 13:43:43 +0000 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > And if so, _will_ you do it? :-) > > Yes, but it may takes some amount of time, it will be not easy patch as > for GNU sort. OK - so if I were to import it, but not link it to the "real" build (IE, it is off by default), that will give you a chance to work on it, no? > BTW, what exactly is urgent in sort replacement idea? As I see by first > look, BSD sort as designed will be somewhat faster, but needs lots of > temporary files comparing to GNU sort. The next thing we need to check > _before_ switch efforts is its POSIX conformance. Agreed. I'm not in any hurry - I just happen to have some time at the moment :-) M -- o Mark Murray \_ FreeBSD Services Limited O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 2 11:40:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id 4F27A37B416; Sun, 2 Dec 2001 11:40:32 -0800 (PST) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.11.4/8.9.3) with ESMTP id fB2JeVf20287; Sun, 2 Dec 2001 11:40:31 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200112021940.fB2JeVf20287@beastie.mckusick.com> To: Robert Watson Subject: Re: Enabling Softupdates in default install on -CURRENT Cc: arch@FreeBSD.ORG In-Reply-To: Your message of "Sat, 01 Dec 2001 23:27:30 EST." Date: Sun, 02 Dec 2001 11:40:31 -0800 From: Kirk McKusick Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I believe that soft updates has been well enough tested at this point to make it reasonable to turn it on by default. Doing it in 5.0 is a no-brainer; doing it for 4.5 is probably fine as it does not require any code-base changes. Having it off for the root filesystem seems like the right plan. Primarily for the reasons of running out of space. I have some changes in the works that try to address that problem, but none work well enough to be worth checking in yet. I am still hopeful that one of the ideas will pan out. In the meantime, you should be mounting a memory-based filesystem on /tmp. Indeed you should do that in any event - setting up a memory-based /tmp should be part of the default setup script. Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 2 12:11:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id E4A1C37B405 for ; Sun, 2 Dec 2001 12:11:21 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id fB2KBAI62241; Sun, 2 Dec 2001 12:11:10 -0800 (PST) (envelope-from obrien) Date: Sun, 2 Dec 2001 12:11:09 -0800 From: "David O'Brien" To: Kirk McKusick Cc: arch@FreeBSD.ORG Subject: Re: Enabling Softupdates in default install on -CURRENT Message-ID: <20011202121109.A61912@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <200112021940.fB2JeVf20287@beastie.mckusick.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112021940.fB2JeVf20287@beastie.mckusick.com>; from mckusick@mckusick.com on Sun, Dec 02, 2001 at 11:40:31AM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Dec 02, 2001 at 11:40:31AM -0800, Kirk McKusick wrote: > In the meantime, you should > be mounting a memory-based filesystem on /tmp. Indeed you should > do that in any event - setting up a memory-based /tmp should > be part of the default setup script. Unfortunately we don't have a very satisfying memory-based file system at this time. The last time I tried it (6 mo. ago), md(4) rushed pages out to the backing swap vs. being smarter about what to flush from the buffer cache. I was getting the same performance with a real FFS /tmp and a large amount of core. The malloc(9) mdmfs is always 100% core resident. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 2 12:51: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from green.bikeshed.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id E36D237B405; Sun, 2 Dec 2001 12:50:57 -0800 (PST) Received: from localhost (green@localhost) by green.bikeshed.org (8.11.4/8.11.1) with ESMTP id fB2Kou800339; Sun, 2 Dec 2001 15:50:57 -0500 (EST) (envelope-from green@green.bikeshed.org) Message-Id: <200112022050.fB2Kou800339@green.bikeshed.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: obrien@FreeBSD.ORG Cc: Kirk McKusick , arch@FreeBSD.ORG Subject: Re: Enabling Softupdates in default install on -CURRENT In-Reply-To: Message from "David O'Brien" of "Sun, 02 Dec 2001 12:11:09 PST." <20011202121109.A61912@dragon.nuxi.com> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 02 Dec 2001 15:50:56 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "David O'Brien" wrote: > On Sun, Dec 02, 2001 at 11:40:31AM -0800, Kirk McKusick wrote: > > In the meantime, you should > > be mounting a memory-based filesystem on /tmp. Indeed you should > > do that in any event - setting up a memory-based /tmp should > > be part of the default setup script. > > Unfortunately we don't have a very satisfying memory-based file system > at this time. > > The last time I tried it (6 mo. ago), md(4) rushed pages out to the > backing swap vs. being smarter about what to flush from the buffer > cache. I was getting the same performance with a real FFS /tmp and a > large amount of core. The malloc(9) mdmfs is always 100% core resident. I personally set up a 100MB FFS/SoftUpdates /tmp partition for every computer I install FreeBSD on. I like separating the root fs from the fs for /tmp, plus it means that I don't lose performance by the non-SoftUpdates root fs since /tmp isn't on it. The only reason I have for making it a real partition instead of an mdfs is that I like the space to be preallocated regardless of swap. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 2 13:40:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 5C40B37B421; Sun, 2 Dec 2001 13:40:31 -0800 (PST) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.11.6/8.11.6) with UUCP id fB2LeU404389; Sun, 2 Dec 2001 21:40:30 GMT (envelope-from mark@grondar.za) Received: from grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.org (8.11.6/8.11.6) with ESMTP id fB2LIp039410; Sun, 2 Dec 2001 21:18:51 GMT (envelope-from mark@grondar.za) Message-Id: <200112022118.fB2LIp039410@grimreaper.grondar.org> To: "Brian F. Feldman" Cc: arch@FreeBSD.ORG Subject: Re: Enabling Softupdates in default install on -CURRENT References: <200112022050.fB2Kou800339@green.bikeshed.org> In-Reply-To: <200112022050.fB2Kou800339@green.bikeshed.org> ; from "Brian F. Feldman" "Sun, 02 Dec 2001 15:50:56 EST." Date: Sun, 02 Dec 2001 21:18:51 +0000 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I personally set up a 100MB FFS/SoftUpdates /tmp partition for every > computer I install FreeBSD on. I like separating the root fs from the fs > for /tmp, plus it means that I don't lose performance by the non-SoftUpdates > root fs since /tmp isn't on it. The only reason I have for making it a real > partition instead of an mdfs is that I like the space to be preallocated > regardless of swap. Me, I null-mount /usr/tmp onto /tmp. Works a charm :-) (Of course, /usr is mounted with SU.) M -- o Mark Murray \_ FreeBSD Services Limited O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 2 14:34:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id 60AE537B405; Sun, 2 Dec 2001 14:34:47 -0800 (PST) Date: Sun, 2 Dec 2001 14:34:47 -0800 From: David O'Brien To: Mark Murray Cc: "Brian F. Feldman" , arch@FreeBSD.ORG Subject: Re: Enabling Softupdates in default install on -CURRENT Message-ID: <20011202143447.A28196@hub.freebsd.org> Reply-To: obrien@freebsd.org References: <200112022050.fB2Kou800339@green.bikeshed.org> <200112022118.fB2LIp039410@grimreaper.grondar.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112022118.fB2LIp039410@grimreaper.grondar.org>; from mark@grondar.za on Sun, Dec 02, 2001 at 09:18:51PM +0000 X-Operating-System: FreeBSD 4.4-STABLE Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Dec 02, 2001 at 09:18:51PM +0000, Mark Murray wrote: > Me, I null-mount /usr/tmp onto /tmp. Works a charm :-) (Of course, > /usr is mounted with SU.) That is nice. But what does that have to add to this discussion? Are you suggesting we do that by default from sysinstall? (note /usr/tmp isn't even a standard directory) -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 2 15:34:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 1497437B448; Sun, 2 Dec 2001 15:34:30 -0800 (PST) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.11.6/8.11.6) with UUCP id fB2NYTW05737; Sun, 2 Dec 2001 23:34:29 GMT (envelope-from mark@grondar.za) Received: from grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.org (8.11.6/8.11.6) with ESMTP id fB2NKK040498; Sun, 2 Dec 2001 23:20:20 GMT (envelope-from mark@grondar.za) Message-Id: <200112022320.fB2NKK040498@grimreaper.grondar.org> To: obrien@FreeBSD.ORG Cc: "Brian F. Feldman" , arch@FreeBSD.ORG Subject: Re: Enabling Softupdates in default install on -CURRENT References: <20011202143447.A28196@hub.freebsd.org> In-Reply-To: <20011202143447.A28196@hub.freebsd.org> ; from "David O'Brien" "Sun, 02 Dec 2001 14:34:47 PST." Date: Sun, 02 Dec 2001 23:20:20 +0000 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > On Sun, Dec 02, 2001 at 09:18:51PM +0000, Mark Murray wrote: > > Me, I null-mount /usr/tmp onto /tmp. Works a charm :-) (Of course, > > /usr is mounted with SU.) > > That is nice. But what does that have to add to this discussion? > Are you suggesting we do that by default from sysinstall? > (note /usr/tmp isn't even a standard directory) My point is that null-mounting is a valid and working alternative. /usr/tmp can easily be made into a standard directory. M -- o Mark Murray \_ FreeBSD Services Limited O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 2 16: 9:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 1905737B41A; Sun, 2 Dec 2001 16:09:55 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB309lP93753; Sun, 2 Dec 2001 16:09:47 -0800 (PST) (envelope-from dillon) Date: Sun, 2 Dec 2001 16:09:47 -0800 (PST) From: Matthew Dillon Message-Id: <200112030009.fB309lP93753@apollo.backplane.com> To: Mark Murray Cc: obrien@FreeBSD.ORG, "Brian F. Feldman" , arch@FreeBSD.ORG Subject: Re: Enabling Softupdates in default install on -CURRENT References: <20011202143447.A28196@hub.freebsd.org> <200112022320.fB2NKK040498@grimreaper.grondar.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> (note /usr/tmp isn't even a standard directory) : :My point is that null-mounting is a valid and working alternative. :/usr/tmp can easily be made into a standard directory. : :M :-- :o Mark Murray Yuch. Verses what, simply using a softlink? I've had /tmp softlinked to /var/tmp for years without problems. I don't see any particular reason to create yet another 'standard' temporary directory. We already have two. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 2 16:14: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 593E037B416; Sun, 2 Dec 2001 16:13:59 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB30Dxm93799; Sun, 2 Dec 2001 16:13:59 -0800 (PST) (envelope-from dillon) Date: Sun, 2 Dec 2001 16:13:59 -0800 (PST) From: Matthew Dillon Message-Id: <200112030013.fB30Dxm93799@apollo.backplane.com> To: "Brian F. Feldman" Cc: obrien@FreeBSD.ORG, Kirk McKusick , arch@FreeBSD.ORG Subject: Re: Enabling Softupdates in default install on -CURRENT References: <200112022050.fB2Kou800339@green.bikeshed.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I tell you guys, I *REALLY* hate the idea of using a memory filesystem for /tmp. My softupdates-enabled /var/tmp (/tmp linked to /var/tmp) is 500MB but even with smaller temporary spaces using MFS/MD for it would be the absolute LAST thing I would ever want to do. MFS/MD disk partitions are fine if you have enough memory to cover the size of the partition without screwing up the VM for the rest of the machine, but not so hot in any other scenario. -Matt :> > be mounting a memory-based filesystem on /tmp. Indeed you should :> > do that in any event - setting up a memory-based /tmp should :> > be part of the default setup script. :> :> Unfortunately we don't have a very satisfying memory-based file system :> at this time. :> :> The last time I tried it (6 mo. ago), md(4) rushed pages out to the :> backing swap vs. being smarter about what to flush from the buffer :> cache. I was getting the same performance with a real FFS /tmp and a :> large amount of core. The malloc(9) mdmfs is always 100% core resident. : :I personally set up a 100MB FFS/SoftUpdates /tmp partition for every :computer I install FreeBSD on. I like separating the root fs from the fs :for /tmp, plus it means that I don't lose performance by the non-SoftUpdates :root fs since /tmp isn't on it. The only reason I have for making it a real :partition instead of an mdfs is that I like the space to be preallocated :regardless of swap. :-- : Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 2 16:24:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 71DA837B416 for ; Sun, 2 Dec 2001 16:24:45 -0800 (PST) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.11.6/8.11.6) with UUCP id fB30OaE06197; Mon, 3 Dec 2001 00:24:36 GMT (envelope-from mark@grondar.za) Received: from grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.org (8.11.6/8.11.6) with ESMTP id fB30NY041328; Mon, 3 Dec 2001 00:23:34 GMT (envelope-from mark@grondar.za) Message-Id: <200112030023.fB30NY041328@grimreaper.grondar.org> To: Matthew Dillon Cc: arch@FreeBSD.ORG Subject: Re: Enabling Softupdates in default install on -CURRENT References: <200112030009.fB309lP93753@apollo.backplane.com> In-Reply-To: <200112030009.fB309lP93753@apollo.backplane.com> ; from Matthew Dillon "Sun, 02 Dec 2001 16:09:47 PST." Date: Mon, 03 Dec 2001 00:23:34 +0000 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Verses what, simply using a softlink? I've had /tmp softlinked to > /var/tmp for years without problems. Symlinks break if the thing they point to does not exist. In the null mount case, you still have a dir. > I don't see any particular reason to create yet another 'standard' > temporary directory. We already have two. *Shrug*. I have no strong attraction to this idea. It just works for me. M -- o Mark Murray \_ FreeBSD Services Limited O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 2 16:40:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 2970137B405 for ; Sun, 2 Dec 2001 16:40:56 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB30epM93968; Sun, 2 Dec 2001 16:40:51 -0800 (PST) (envelope-from dillon) Date: Sun, 2 Dec 2001 16:40:51 -0800 (PST) From: Matthew Dillon Message-Id: <200112030040.fB30epM93968@apollo.backplane.com> To: Mark Murray Cc: arch@FreeBSD.ORG Subject: Re: Enabling Softupdates in default install on -CURRENT References: <200112030009.fB309lP93753@apollo.backplane.com> <200112030023.fB30NY041328@grimreaper.grondar.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :> Verses what, simply using a softlink? I've had /tmp softlinked to :> /var/tmp for years without problems. : :Symlinks break if the thing they point to does not exist. In the null :mount case, you still have a dir. Not really relevant. There is no reason why you can't have a /var/tmp on the / partition for /tmp to point to if /var isn't mounted. I usually don't bother, but it works just fine. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 2 17:17:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id 37D1F37B405; Sun, 2 Dec 2001 17:17:08 -0800 (PST) Received: from pool0252.cvx25-bradley.dialup.earthlink.net ([209.179.216.252] helo=peter3.wemm.org) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16AhjA-0002ub-00; Sun, 02 Dec 2001 17:17:02 -0800 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id fB31GsO01927; Sun, 2 Dec 2001 17:16:54 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 01CE13808; Sun, 2 Dec 2001 17:16:54 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Mark Murray Cc: obrien@FreeBSD.ORG, "Brian F. Feldman" , arch@FreeBSD.ORG Subject: Re: Enabling Softupdates in default install on -CURRENT In-Reply-To: <200112022320.fB2NKK040498@grimreaper.grondar.org> Date: Sun, 02 Dec 2001 17:16:53 -0800 From: Peter Wemm Message-Id: <20011203011654.01CE13808@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mark Murray wrote: > > On Sun, Dec 02, 2001 at 09:18:51PM +0000, Mark Murray wrote: > > > Me, I null-mount /usr/tmp onto /tmp. Works a charm :-) (Of course, > > > /usr is mounted with SU.) > > > > That is nice. But what does that have to add to this discussion? > > Are you suggesting we do that by default from sysinstall? > > (note /usr/tmp isn't even a standard directory) > > My point is that null-mounting is a valid and working alternative. > /usr/tmp can easily be made into a standard directory. No it cannot. The whole point of the /usr and /var split was to keep /usr a stable, mostly unchanging file system. All of the dynamic activity is over in /var, which you can afford to trash during a crash. I've done this before: (single user login) # mkdir -p /var/tmp # rm -rf /tmp # ln -s /var/tmp /tmp .. That provides a directory even when /var isn't mounted. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 2 18:47:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id A328B37B416; Sun, 2 Dec 2001 18:47:55 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id fB32lrU112576; Sun, 2 Dec 2001 21:47:53 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200112021023.fB2ANMi91290@apollo.backplane.com> References: <200112021023.fB2ANMi91290@apollo.backplane.com> Date: Sun, 2 Dec 2001 21:47:51 -0500 To: Matthew Dillon From: Garance A Drosihn Subject: Re: Enabling Softupdates in default install on -CURRENT Cc: Robert Watson , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 2:23 AM -0800 12/2/01, Matthew Dillon wrote: > I agree. / is still a problem - I have softupdates enabled on > my 128M / partitions and if I 'make install' a kernel twice in > a row the filesystem runs out of space and the second install > fails. But that's the only time I've ever managed to run a > softupdates filesystem out of space. If we incorporated a couple > of 'sync's (like eight of them) at the beginning of a kernel or > world install target it would probably be safe enough. Actually, I wrote some changes to the way 'installkernel' works in -stable which makes it MUCH less likely to run into trouble on a softupdates partition (among other improvements). The thing is, it would make a lot of sense to have those same changes in -current, and I haven't had the time to try rewriting them. (I did compare the relevant makefiles in -stable and -current, and they are different enough that I'd have to think about how to change it...) Let me stumble thru to the end of the semester here, and then I should have some time to revisit those changes. At that point I'll try to get something together for the makefiles in both branches. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 4 13:11:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 7293537B416 for ; Tue, 4 Dec 2001 13:11:56 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id fB4LBu303554 for freebsd-arch@freebsd.org; Tue, 4 Dec 2001 13:11:56 -0800 (PST) (envelope-from obrien) Date: Tue, 4 Dec 2001 13:11:52 -0800 From: "David O'Brien" To: freebsd-arch@freebsd.org Subject: WARNS granularity Message-ID: <20011204131152.A73842@dragon.nuxi.com> Reply-To: obrien@freebsd.org Mail-Followup-To: freebsd-arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG IMO our WARNS values {0,1,2} are not granular enough. I would like to make 1 ==> -Werror only. This would help prevent regressions with sources that do not produces warnings with the default GCC warnings. WARNS=2 would add: -Wall I think having a WARNS level that is just -Wall is useful as -Wall is the most common thing GCC users compile with if they use any warnings at all. WARNS=3 would be the same as today's `1', which adds: -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized WARNS=4 would be the same as today's `2', which adds: -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow Objections? Improvements to the idea? -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 4 13:25:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id 123C337B7AC for ; Tue, 4 Dec 2001 13:24:24 -0800 (PST) Received: (qmail 6552 invoked from network); 4 Dec 2001 21:24:23 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 4 Dec 2001 21:24:23 -0000 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: <20011204131152.A73842@dragon.nuxi.com> Date: Tue, 04 Dec 2001 13:24:18 -0800 (PST) From: John Baldwin To: "David O'Brien" Subject: RE: WARNS granularity Cc: freebsd-arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 04-Dec-01 David O'Brien wrote: > IMO our WARNS values {0,1,2} are not granular enough. > > I would like to make 1 ==> -Werror only. This would help prevent > regressions with sources that do not produces warnings with the default > GCC warnings. > > WARNS=2 would add: > -Wall > I think having a WARNS level that is just -Wall is useful as -Wall is the > most common thing GCC users compile with if they use any warnings at all. > > WARNS=3 would be the same as today's `1', which adds: > -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Wno-uninitialized > > WARNS=4 would be the same as today's `2', which adds: > -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow > > Objections? Improvements to the idea? Since -Wno-uninitialized actually turns off some warnings, I think you would want it in WARNS=2 as well. One question: is the WARNS thing intended to be compatible with some other OS? Oh, and -Wcast-align looks like it could be useful in tracking down those pesky alignment faults on non-i386, so putting that in WARNS=4 might be useful. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 4 13:34:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 34D2C37B73C; Tue, 4 Dec 2001 13:33:53 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id fB4LXrq21617; Tue, 4 Dec 2001 13:33:53 -0800 (PST) (envelope-from obrien) Date: Tue, 4 Dec 2001 13:33:53 -0800 From: "David O'Brien" To: John Baldwin Cc: freebsd-arch@FreeBSD.org Subject: Re: WARNS granularity Message-ID: <20011204133353.A21551@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org Mail-Followup-To: freebsd-arch@freebsd.org References: <20011204131152.A73842@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Tue, Dec 04, 2001 at 01:24:18PM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Dec 04, 2001 at 01:24:18PM -0800, John Baldwin wrote: > Oh, and -Wcast-align looks like it could be useful in tracking down > those pesky alignment faults on non-i386, so putting that in WARNS=4 > might be useful. If our existing WARNS=2 code will not handle that addition, I would maybe suggest a level `5' then. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 5 22:56:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from bazooka.trit.org (bazooka.trit.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 3015537B405 for ; Wed, 5 Dec 2001 22:56:37 -0800 (PST) Received: by bazooka.trit.org (Postfix, from userid 1000) id 9E9953E4B; Thu, 6 Dec 2001 06:56:33 +0000 (UTC) Received: from bazooka (localhost [127.0.0.1]) by bazooka.trit.org (Postfix) with ESMTP id 9D4853C13D for ; Thu, 6 Dec 2001 06:56:33 +0000 (UTC) To: arch@freebsd.org Subject: MFC'ing xucred definition Date: Thu, 06 Dec 2001 06:56:28 +0000 From: Dima Dorfman Message-Id: <20011206065633.9E9953E4B@bazooka.trit.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Is there any reason the definition of struct xucred shouldn't be MFC'd? I'd like to MFC my LOCAL_PEERCRED/getpeereid() changes, and would prefer not to have to use the old ucred for a new interface. I'm not planning to merge the changes to existing interfaces to use xucred as was done in current (this would probably cause unnecessary pain in -stable), I just want to merge the definition. Here's the change I'm talking about. Any objections? Thanks. Index: ucred.h =================================================================== RCS file: /ref/cvsf/src/sys/sys/ucred.h,v retrieving revision 1.14.2.4 diff -u -r1.14.2.4 ucred.h --- ucred.h 2001/05/17 03:51:28 1.14.2.4 +++ ucred.h 2001/11/27 21:30:40 @@ -53,6 +53,19 @@ #define cr_gid cr_groups[0] #define NOCRED ((struct ucred *)0) /* no credential available */ #define FSCRED ((struct ucred *)-1) /* filesystem credential */ + +/* + * This is the external representation of struct ucred, based upon the + * size of a 4.2-RELEASE struct ucred. There will probably never be + * any need to change the size of this or layout of its used fields. + */ +struct xucred { + u_short _cr_unused0; /* compatibility with old ucred */ + uid_t cr_uid; /* effective user id */ + short cr_ngroups; /* number of groups */ + gid_t cr_groups[NGROUPS]; /* groups */ + void *_cr_unused1; /* compatibility with old ucred */ +}; #ifdef _KERNEL To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 6 11:27:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 37F6237B417 for ; Thu, 6 Dec 2001 11:27:16 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id D7F4781E0A; Thu, 6 Dec 2001 13:27:15 -0600 (CST) Date: Thu, 6 Dec 2001 13:27:15 -0600 From: Alfred Perlstein To: Dima Dorfman Cc: arch@freebsd.org Subject: Re: MFC'ing xucred definition Message-ID: <20011206132715.X92148@elvis.mu.org> References: <20011206065633.9E9953E4B@bazooka.trit.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011206065633.9E9953E4B@bazooka.trit.org>; from dima@trit.org on Thu, Dec 06, 2001 at 06:56:28AM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Dima Dorfman [011206 00:56] wrote: > Is there any reason the definition of struct xucred shouldn't be > MFC'd? I'd like to MFC my LOCAL_PEERCRED/getpeereid() changes, and > would prefer not to have to use the old ucred for a new interface. > I'm not planning to merge the changes to existing interfaces to use > xucred as was done in current (this would probably cause unnecessary > pain in -stable), I just want to merge the definition. > > Here's the change I'm talking about. Any objections? Not if this is this extent of the patch, let's not break all the ucred interfaces in -stable though, that would be bad. > Index: ucred.h > =================================================================== -- -Alfred Perlstein [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.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 6 13:30:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 32EA737B62B for ; Thu, 6 Dec 2001 13:29:42 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fB6LT4i28807; Thu, 6 Dec 2001 16:29:04 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 6 Dec 2001 16:29:04 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Dima Dorfman Cc: arch@freebsd.org Subject: Re: MFC'ing xucred definition In-Reply-To: <20011206065633.9E9953E4B@bazooka.trit.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I've actually been thinking about modifying xucred in -CURRENT to export additional information from a kernel ucred, such as real and saved ids, now that we have that information in ucred. Before we MFC xucred, it might make sense to make a few tweaks to xucred, including changing the first _cr_unused0 into a version number, and teaching applications how to understand the version number. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services On Thu, 6 Dec 2001, Dima Dorfman wrote: > Is there any reason the definition of struct xucred shouldn't be > MFC'd? I'd like to MFC my LOCAL_PEERCRED/getpeereid() changes, and > would prefer not to have to use the old ucred for a new interface. > I'm not planning to merge the changes to existing interfaces to use > xucred as was done in current (this would probably cause unnecessary > pain in -stable), I just want to merge the definition. > > Here's the change I'm talking about. Any objections? > > Thanks. > > Index: ucred.h > =================================================================== > RCS file: /ref/cvsf/src/sys/sys/ucred.h,v > retrieving revision 1.14.2.4 > diff -u -r1.14.2.4 ucred.h > --- ucred.h 2001/05/17 03:51:28 1.14.2.4 > +++ ucred.h 2001/11/27 21:30:40 > @@ -53,6 +53,19 @@ > #define cr_gid cr_groups[0] > #define NOCRED ((struct ucred *)0) /* no credential available */ > #define FSCRED ((struct ucred *)-1) /* filesystem credential */ > + > +/* > + * This is the external representation of struct ucred, based upon the > + * size of a 4.2-RELEASE struct ucred. There will probably never be > + * any need to change the size of this or layout of its used fields. > + */ > +struct xucred { > + u_short _cr_unused0; /* compatibility with old ucred */ > + uid_t cr_uid; /* effective user id */ > + short cr_ngroups; /* number of groups */ > + gid_t cr_groups[NGROUPS]; /* groups */ > + void *_cr_unused1; /* compatibility with old ucred */ > +}; > > #ifdef _KERNEL > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 6 14:51:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.tgd.net (pop3-ssl.tgd.net [209.81.25.10]) by hub.freebsd.org (Postfix) with ESMTP id C1A3D37B41A; Thu, 6 Dec 2001 14:51:17 -0800 (PST) Received: by mail.tgd.net (Postfix, from userid 1001) id 35B4820F13; Thu, 6 Dec 2001 14:49:05 -0800 (PST) Date: Thu, 6 Dec 2001 14:49:05 -0800 From: Sean Chittenden To: arch@FreeBSD.org Cc: tobez@FreeBSD.org Subject: Perl 5.6.1 in the base.... Message-ID: <20011206144905.B73442@ninja1.internal> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Isn't it getting close to the time when we should start thinking about integrating Perl 5.6.1 into the base system? Since 5.0 has been pushed back a year, I'm getting antsy to see the upgrade happen sooner rather than later. Developing on 5.005_03 and then copying scripts to a 5.6 box used to work alright, but I recently have been bitten by the _huge_ difference with mkdir. In perl 5.005_03: mkdir FILENAME,MODE In perl 5.6.1: mkdir FILENAME,MASK mkdir FILENAME Writting a wrapper around this is ugly and shouldn't be necessary. Perl 5.6 came out two years ago. Granted it was an abomination of in terms of backwards compatability, I think that most of the free world has swallowed their gripes and has moved on. Can we? I think we're hard pressed to convince anyone that we're helping out by hanging onto 5.005_03 in the base. At this point, I think it'd be reasonable to make the existing perl install a port and then make perl 5.6 apart of the base. Right now I can't install Xerxes-P because it requires the Unicode support found in Perl 5.6. That's a pretty big show stopper and the #1 reason why I still have some Solaris boxen (read: non-FreeBSD) sitting around (can upgrade/thrash the local install of Perl all I want and it doesn't hurt when it comes time to upgrade). Can someone take this issue up on either -core or even here? I personally would be an advocate of having _both_ versions of perl become packages/ports and then at sys-install time you're forced to choose one of the two versions (need at least one version of perl installed). 4.5 seems like a good time to get 5.6 out there, IMHO. -sc -- Sean Chittenden To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 6 15: 6: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mtbaker.tfm.com (mtbaker.tfm.com [192.231.224.2]) by hub.freebsd.org (Postfix) with ESMTP id C244337B405; Thu, 6 Dec 2001 15:06:02 -0800 (PST) Received: (from db@localhost) by mtbaker.tfm.com (8.11.1/8.11.1) id fB6N5xt17790; Thu, 6 Dec 2001 15:05:59 -0800 (PST) From: Diane Bruce Message-Id: <200112062305.fB6N5xt17790@mtbaker.tfm.com> Subject: Re: Perl 5.6.1 in the base.... In-Reply-To: <20011206144905.B73442@ninja1.internal> "from Sean Chittenden at Dec 6, 2001 02:49:05 pm" To: Sean Chittenden Date: Thu, 6 Dec 2001 15:05:59 -0800 (PST) Cc: arch@FreeBSD.ORG, tobez@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL78 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sean Chittenden says: > Isn't it getting close to the time when we should start thinking about > integrating Perl 5.6.1 into the base system? Since 5.0 has been More like its time to remove perl altogether from the base. -- Diane Bruce, http://www.db.net/~db db@db.net --- I got bored with the last witty aphorism. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 6 16:10: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 2890D37B405; Thu, 6 Dec 2001 16:09:57 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id A80AE81E0A; Thu, 6 Dec 2001 18:09:51 -0600 (CST) Date: Thu, 6 Dec 2001 18:09:51 -0600 From: Alfred Perlstein To: Sean Chittenden Cc: arch@FreeBSD.org, tobez@FreeBSD.org Subject: Re: Perl 5.6.1 in the base.... Message-ID: <20011206180951.F92148@elvis.mu.org> References: <20011206144905.B73442@ninja1.internal> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011206144905.B73442@ninja1.internal>; from sean@chittenden.org on Thu, Dec 06, 2001 at 02:49:05PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Sean Chittenden [011206 16:51] wrote: > > Can someone take this issue up on either -core or even here? I > personally would be an advocate of having _both_ versions of perl > become packages/ports and then at sys-install time you're forced to > choose one of the two versions (need at least one version of perl > installed). 4.5 seems like a good time to get 5.6 out there, IMHO. At this point it's more an issue of man power than if we want to do it or not. It sure seems like a good idea, do you think you can contribute the patches needed? Can anyone else get working on this? -- -Alfred Perlstein [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.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 6 16:28:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by hub.freebsd.org (Postfix) with ESMTP id 0740037B419 for ; Thu, 6 Dec 2001 16:28:35 -0800 (PST) Received: (qmail 13552 invoked from network); 7 Dec 2001 00:28:33 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 7 Dec 2001 00:28:33 -0000 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: <200112062305.fB6N5xt17790@mtbaker.tfm.com> Date: Thu, 06 Dec 2001 16:28:27 -0800 (PST) From: John Baldwin To: Diane Bruce Subject: Re: Perl 5.6.1 in the base.... Cc: tobez@FreeBSD.ORG, arch@FreeBSD.ORG, Sean Chittenden Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 06-Dec-01 Diane Bruce wrote: > Sean Chittenden says: >> Isn't it getting close to the time when we should start thinking about >> integrating Perl 5.6.1 into the base system? Since 5.0 has been > > More like its time to remove perl altogether from the base. Unfortunately the kernel build needs it. However, one can _always_ easily install the port to get perl 5.6.x in -stable. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 6 16:31:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.tgd.net (pop3-ssl.tgd.net [209.81.25.10]) by hub.freebsd.org (Postfix) with ESMTP id 7F1C437B405; Thu, 6 Dec 2001 16:31:56 -0800 (PST) Received: by mail.tgd.net (Postfix, from userid 1001) id 178E020F16; Thu, 6 Dec 2001 16:29:43 -0800 (PST) Date: Thu, 6 Dec 2001 16:29:43 -0800 From: Sean Chittenden To: Alfred Perlstein Cc: arch@FreeBSD.org, tobez@FreeBSD.org Subject: Re: Perl 5.6.1 in the base.... Message-ID: <20011206162943.A74937@ninja1.internal> References: <20011206144905.B73442@ninja1.internal> <20011206180951.F92148@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011206180951.F92148@elvis.mu.org>; from "bright@mu.org" on Thu, Dec 06, 2001 at = 06:09:51PM 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-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > Can someone take this issue up on either -core or even here? I > > personally would be an advocate of having _both_ versions of perl > > become packages/ports and then at sys-install time you're forced to > > choose one of the two versions (need at least one version of perl > > installed). 4.5 seems like a good time to get 5.6 out there, IMHO. > > At this point it's more an issue of man power than if we want to do > it or not. It sure seems like a good idea, do you think you can > contribute the patches needed? I know I'm going to be busy for ~2 weeks and will have only limited amounts of time to work on this, but after that I should be wide open in terms of after hrs time. If I start chiseling away at this w/ a few other folks, however, is there the support/desire to integrate the changes? The reason I lobbed this out (and promptly ran for the door) was that I am under the impression that there is some precedent _not_ to use/like Perl 5.6. > Can anyone else get working on this? Better question: is someone already working on this? I seem to recall someone already had a large chunk of this done. -sc -- Sean Chittenden To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 6 16:33:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by hub.freebsd.org (Postfix) with ESMTP id C0ABE37B41A for ; Thu, 6 Dec 2001 16:33:22 -0800 (PST) Received: (qmail 9630 invoked from network); 7 Dec 2001 00:33:22 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 7 Dec 2001 00:33:22 -0000 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: <20011206162943.A74937@ninja1.internal> Date: Thu, 06 Dec 2001 16:33:17 -0800 (PST) From: John Baldwin To: Sean Chittenden Subject: Re: Perl 5.6.1 in the base.... Cc: tobez@FreeBSD.org, arch@FreeBSD.org, Alfred Perlstein Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 07-Dec-01 Sean Chittenden wrote: >> > Can someone take this issue up on either -core or even here? I >> > personally would be an advocate of having _both_ versions of perl >> > become packages/ports and then at sys-install time you're forced to >> > choose one of the two versions (need at least one version of perl >> > installed). 4.5 seems like a good time to get 5.6 out there, IMHO. >> >> At this point it's more an issue of man power than if we want to do >> it or not. It sure seems like a good idea, do you think you can >> contribute the patches needed? > > I know I'm going to be busy for ~2 weeks and will have only limited > amounts of time to work on this, but after that I should be wide open > in terms of after hrs time. If I start chiseling away at this w/ a > few other folks, however, is there the support/desire to integrate the > changes? The reason I lobbed this out (and promptly ran for the door) > was that I am under the impression that there is some precedent _not_ > to use/like Perl 5.6. Nope. The perl in -current is 5.6.0. The problem is that the Perl upgrades are quite hard to do and get right. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 6 16:56:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp.ieg.com.br (huxley.protocoloweb.com.br [200.185.63.26]) by hub.freebsd.org (Postfix) with ESMTP id DFD1537B426 for ; Thu, 6 Dec 2001 16:55:52 -0800 (PST) Received: from TmpStr (200-207-52-210.dsl.telesp.net.br [200.207.52.210]) by smtp.ieg.com.br (ieG relay/8.9.3) with SMTP id fB70t3D95731 for ; Thu, 6 Dec 2001 22:55:04 -0200 (BRST) Message-Id: <200112070055.fB70t3D95731@smtp.ieg.com.br> Reply-To: "Keila - Curitiba" From: "Keila - Curitiba" To: "" Organization: X-Priority: 3 X-MSMail-Priority: Normal Subject: CONVITE HP ALERTA Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 6 Dec 2001 22:59:08 -0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Olá! Veja meu site pessoal. Basta clicar no endereço abaixo. GARANTO SER SUI-GENERIS - CLIQUE ABAIXO: http://www.pastorinha.atfreeweb.com Mais de 162.000 internautas visitaram a PG., existe 6 Álbuns: Se você quiser, por favor, indique minha Home Page, a outros Internautas. Mais detalhes, se comunique, passe um e-mail, que responderei brevemente. Dentro da Home Page, ao lado das fotos, você poderá saber muito mais sobre mim! Obrigada. e-mail: arosadesaron@zipmail.com.br Beijos:- Keila - Curitiba - Pr - Podes falar comigo, direto dela. Brevemente uma Carta Aberta. - Embora derrubem a página eu a subo em 3 horas novamente. "Esta mensagem é enviada com a complacência da nova legislação sobre correio eletrônico, Seção 301, Parágrafo (a) (2) (c) Decreto S. 1618, Título Terceiro aprovado pelo "105º Congresso Base das Normativas Internacionais sobre o SPAM". Este E-mail não poderá ser considerado SPAM quando incluir uma forma de ser removido. Para ser removido de futuros correios, simplesmente responda indicando no Assunto: REMOVER" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 6 18: 7:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id BF05C37B405; Thu, 6 Dec 2001 18:07:51 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011207020751.YQBT24045.rwcrmhc53.attbi.com@peter3.wemm.org>; Fri, 7 Dec 2001 02:07:51 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id fB727ps18590; Thu, 6 Dec 2001 18:07:51 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 29B40380D; Thu, 6 Dec 2001 18:07:51 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: John Baldwin Cc: Sean Chittenden , tobez@FreeBSD.ORG, arch@FreeBSD.ORG, Alfred Perlstein Subject: Re: Perl 5.6.1 in the base.... In-Reply-To: Date: Thu, 06 Dec 2001 18:07:51 -0800 From: Peter Wemm Message-Id: <20011207020751.29B40380D@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG John Baldwin wrote: > > On 07-Dec-01 Sean Chittenden wrote: > >> > Can someone take this issue up on either -core or even here? I > >> > personally would be an advocate of having _both_ versions of perl > >> > become packages/ports and then at sys-install time you're forced to > >> > choose one of the two versions (need at least one version of perl > >> > installed). 4.5 seems like a good time to get 5.6 out there, IMHO. > >> > >> At this point it's more an issue of man power than if we want to do > >> it or not. It sure seems like a good idea, do you think you can > >> contribute the patches needed? > > > > I know I'm going to be busy for ~2 weeks and will have only limited > > amounts of time to work on this, but after that I should be wide open > > in terms of after hrs time. If I start chiseling away at this w/ a > > few other folks, however, is there the support/desire to integrate the > > changes? The reason I lobbed this out (and promptly ran for the door) > > was that I am under the impression that there is some precedent _not_ > > to use/like Perl 5.6. > > Nope. The perl in -current is 5.6.0. The problem is that the Perl upgrades > are quite hard to do and get right. My memory was that somebody signed up to do this update and take over from Mark Murray, but it appears that nothing came of it (or my memory is faulty, which is also distinctly likely). If we dont have any takers, I'll take a shot at it soon. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 0:52:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id 904BC37B417; Fri, 7 Dec 2001 00:52:42 -0800 (PST) Received: from winston.freebsd.org (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id fB78qMq39096; Fri, 7 Dec 2001 00:52:22 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: Sean Chittenden Cc: Alfred Perlstein , arch@FreeBSD.ORG, tobez@FreeBSD.ORG Subject: Re: Perl 5.6.1 in the base.... In-Reply-To: Message from Sean Chittenden of "Thu, 06 Dec 2001 16:29:43 PST." <20011206162943.A74937@ninja1.internal> Date: Fri, 07 Dec 2001 00:52:22 -0800 Message-ID: <39092.1007715142@winston.freebsd.org> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I don't recall seeing anything to the effect of "death before 5.6", and any complaints about backwards-compatibility pretty much expired a year or so ago, as you've already noted, so I'd say it's just resource constrained at this point. I also don't think it needs to become a core issue unless -arch devolves into flames over it or something, an event I don't see happening. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 1:26:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from portege.clkao.org (61-219-5-120.HINET-IP.hinet.net [61.219.5.120]) by hub.freebsd.org (Postfix) with ESMTP id E934837B405; Fri, 7 Dec 2001 01:26:07 -0800 (PST) Received: (from clkao@localhost) by portege.clkao.org (8.11.6/8.11.5) id fB79PHO20327; Fri, 7 Dec 2001 17:25:17 +0800 (CST) (envelope-from clkao) Date: Fri, 7 Dec 2001 17:25:16 +0800 From: Chia-liang Kao To: Peter Wemm Cc: John Baldwin , Sean Chittenden , tobez@FreeBSD.ORG, arch@FreeBSD.ORG, Alfred Perlstein Subject: Re: Perl 5.6.1 in the base.... Message-ID: <20011207092516.GA20217@clk.cirx.org> References: <20011207020751.29B40380D@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline In-Reply-To: <20011207020751.29B40380D@overcee.netplex.com.au> User-Agent: Mutt/1.3.23.2i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In a private mail conversation with tobez back several months ago, he mentioned he'll do the import soon. So I guess he signed up for this. I would really like to see -current to have 5.7.2 since 5.8.0 is coming, while -stable to have 5.6.1 as it had been proven quite stable. It'd also be nice to bring tobez's wonderful BSDPAN to -stable along with perl 5.6.1 On Thu, Dec 06, 2001 at 06:07:51PM -0800, Peter Wemm wrote: > > Nope. The perl in -current is 5.6.0. The problem is that the > > Perl upgrades are quite hard to do and get right. > My memory was that somebody signed up to do this update and take over from > Mark Murray, but it appears that nothing came of it (or my memory is > faulty, which is also distinctly likely). > > If we dont have any takers, I'll take a shot at it soon. Cheers, CLK --Qxx1br4bt0+wmkIi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE8EIr7k1XldlEkA5YRAoi5AKCE5XJG9+IyX5Ap3WRDysVFtV/ZmgCghf2e kna8tfdNONYCPLcJP8piyBY= =r0Tl -----END PGP SIGNATURE----- --Qxx1br4bt0+wmkIi-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 1:55: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from maisoncorbeil.com (h-64-105-236-101.CHCGILGM.covad.net [64.105.236.101]) by hub.freebsd.org (Postfix) with ESMTP id 0C03537B425 for ; Fri, 7 Dec 2001 01:52:13 -0800 (PST) Received: from sniperdev.com (24.0.212.26) by maisoncorbeil.com with SMTP (Eudora Internet Mail Server 3.0.3); Thu, 6 Dec 2001 19:49:00 -0600 From: "Nick Cargill" To: Subject: Mime-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Date: Thu, 6 Dec 2001 19:11:34 -0800 Reply-To: "Nick Cargill" Content-Transfer-Encoding: 8bit Message-ID: <1204432756-1721688@maisoncorbeil.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dear Sir or Madam:

Dear Media Executive,

 

I would like to speak to you regarding our new content management solution (CMS) called the “Oven” - it has been specifically developed for publishers.  In a nutshell, if a company has extensive content such as articles and media (jpgs, gifs, word documents, pdf’s, avi’s, mpg’s, mov’s) they can push this content to the web in minutes without having any programming skills. The same people creating the content can update the website daily through a web-enabled interface.

 

Publishers who have an existing website, push your content to the web faster and cheaper today.  Publishers without a web presence get one now!

           

Alice Plain, Jeep King of the Mountain, had this to say, "This is amazing! I cannot believe how easy it is to manage and update the Website, I have always wanted to take a class to learn more about the Internet, but now I don’t have to, anyone that can type can do this."
 

We have different solutions to meet your specific needs!

 

Single License – for individual websites, we will either integrate seamlessly with your existing site or build from the ground up.

Multi License – For publishers that manage multiple websites.

Enterprise (hosted or non-hosted) – Ideal for publishers or organizations that are interested in purchasing the Oven’s base technology and would like to implement a great deal of customization.   These clients continue to benefit from core improvements and feature enhancements to the Oven at no cost.

 

For more information, visit http://www.sniperdev.com (this website is also powered by our product).

 

If you wish to be removed from this newsletter just click here.

To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 4:46:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tao.org.uk (genius.tao.org.uk [212.135.162.51]) by hub.freebsd.org (Postfix) with ESMTP id 2926E37BAF4; Fri, 7 Dec 2001 04:43:27 -0800 (PST) Received: by tao.org.uk (Postfix, from userid 100) id EC04346E; Fri, 7 Dec 2001 12:43:12 +0000 (GMT) Date: Fri, 7 Dec 2001 12:43:12 +0000 From: Josef Karthauser To: Chia-liang Kao Cc: Peter Wemm , John Baldwin , Sean Chittenden , tobez@FreeBSD.ORG, arch@FreeBSD.ORG, Alfred Perlstein Subject: Re: Perl 5.6.1 in the base.... Message-ID: <20011207124312.B76875@tao.org.uk> References: <20011207020751.29B40380D@overcee.netplex.com.au> <20011207092516.GA20217@clk.cirx.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="f2QGlHpHGjS2mn6Y" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011207092516.GA20217@clk.cirx.org>; from clkao@clkao.org on Fri, Dec 07, 2001 at 05:25:16PM +0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --f2QGlHpHGjS2mn6Y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 07, 2001 at 05:25:16PM +0800, Chia-liang Kao wrote: > In a private mail conversation with tobez back several months ago, he > mentioned he'll do the import soon. So I guess he signed up for this. >=20 > I would really like to see -current to have 5.7.2 since 5.8.0 is > coming, while -stable to have 5.6.1 as it had been proven quite > stable. It'd also be nice to bring tobez's wonderful BSDPAN to -stable > along with perl 5.6.1 This is pending on some other packages issues. Joe --f2QGlHpHGjS2mn6Y Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjwQuWAACgkQXVIcjOaxUBYIHgCfcxUW3aKkqO1xQDknaJZ9KaE/ tRgAn1TXQ936M8628kVQ1MbatkFBjkP/ =b4af -----END PGP SIGNATURE----- --f2QGlHpHGjS2mn6Y-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 5:34:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 484E637B416 for ; Fri, 7 Dec 2001 05:34:16 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16CLA6-0008H2-00; Fri, 07 Dec 2001 15:35:34 +0200 From: Sheldon Hearn To: Matthew Dillon Cc: Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems In-reply-to: Your message of "Sat, 24 Nov 2001 10:45:22 PST." <200111241845.fAOIjM377587@apollo.backplane.com> Date: Fri, 07 Dec 2001 15:35:34 +0200 Message-ID: <31807.1007732134@axl.seasidesoftware.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 24 Nov 2001 10:45:22 PST, Matthew Dillon wrote: > Sheldon, I think you have a go to change the newfs default. Do it! Hi Matt, I already have patches for newfs, sysinstall and the tuning(7) manual page which simply make 16384/2048 the default. However, I remember people expressing concerns with using these parameters for very small filesystems. I can't find any negative performance impact for very small filesystems. The only other thing I can think of is what obrien suggested. He told me that it might be that people are wary of a filesystem that contains only a single cylinder group, as this means you only have one superblock. Is this really something to worry about? Is there some other reason why we shouldn't just make 16384/2048 the blanket default? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 5:40:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 8030737B416; Fri, 7 Dec 2001 05:40:31 -0800 (PST) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.11.6/8.11.6) with UUCP id fB7De4B99330; Fri, 7 Dec 2001 13:40:04 GMT (envelope-from mark@grondar.za) Received: from grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.org (8.11.6/8.11.6) with ESMTP id fB7DbmU45046; Fri, 7 Dec 2001 13:37:48 GMT (envelope-from mark@grondar.za) Message-Id: <200112071337.fB7DbmU45046@grimreaper.grondar.org> To: Diane Bruce Cc: Sean Chittenden , arch@FreeBSD.ORG, tobez@FreeBSD.ORG Subject: Re: Perl 5.6.1 in the base.... References: <200112062305.fB6N5xt17790@mtbaker.tfm.com> In-Reply-To: <200112062305.fB6N5xt17790@mtbaker.tfm.com> ; from Diane Bruce "Thu, 06 Dec 2001 15:05:59 PST." Date: Fri, 07 Dec 2001 13:37:47 +0000 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Sean Chittenden says: > > Isn't it getting close to the time when we should start thinking about > > integrating Perl 5.6.1 into the base system? Since 5.0 has been > > More like its time to remove perl altogether from the base. I'm sympathetic :-) To do this, we'd need to rewrite the perl scripts that are currently in the main system. Wanna give a hand? :-) M -- o Mark Murray \_ FreeBSD Services Limited O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 5:45:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gidgate.gid.co.uk (gid.co.uk [194.32.164.225]) by hub.freebsd.org (Postfix) with ESMTP id CECF637B419 for ; Fri, 7 Dec 2001 05:45:23 -0800 (PST) Received: (from rb@localhost) by gidgate.gid.co.uk (8.9.3/8.9.3) id NAA24694; Fri, 7 Dec 2001 13:44:39 GMT (envelope-from rb) Message-Id: <4.3.2.7.2.20011207134031.00bbfc40@gid.co.uk> X-Sender: rbmail@gid.co.uk X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 07 Dec 2001 13:44:36 +0000 To: Sheldon Hearn From: Bob Bishop Subject: Re: Using a larger block size on large filesystems Cc: Kirk McKusick , freebsd-arch@FreeBSD.ORG, Matthew Dillon In-Reply-To: <31807.1007732134@axl.seasidesoftware.co.za> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, At 15:35 07/12/01 +0200, Sheldon Hearn wrote: >[...] >The only other thing I can think of is what obrien suggested. He told >me that it might be that people are wary of a filesystem that contains >only a single cylinder group, as this means you only have one >superblock. > >Is this really something to worry about? [etc] Depends how good you are at patching superblocks. Getting the main superblock trashed by power or harware hiccups is not that uncommon. -- Bob Bishop +44 (0)118 977 4017 rb@gid.co.uk fax +44 (0)118 989 4254 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 6:14:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 2469537B416 for ; Fri, 7 Dec 2001 06:14:23 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16CLmr-0008SX-00; Fri, 07 Dec 2001 16:15:37 +0200 From: Sheldon Hearn To: Bob Bishop Cc: Kirk McKusick , freebsd-arch@FreeBSD.ORG, Matthew Dillon Subject: Re: Using a larger block size on large filesystems In-reply-to: Your message of "Fri, 07 Dec 2001 13:44:36 GMT." <4.3.2.7.2.20011207134031.00bbfc40@gid.co.uk> Date: Fri, 07 Dec 2001 16:15:36 +0200 Message-ID: <32520.1007734536@axl.seasidesoftware.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 07 Dec 2001 13:44:36 GMT, Bob Bishop wrote: > >The only other thing I can think of is what obrien suggested. He told > >me that it might be that people are wary of a filesystem that contains > >only a single cylinder group, as this means you only have one > >superblock. > > > >Is this really something to worry about? [etc] > > Depends how good you are at patching superblocks. Getting the main > superblock trashed by power or harware hiccups is not that uncommon. Okay, in that case, the threshold needs to be 196MB, from which size upward we're guaranteed of at least one backup superblock. I'll get cracking on making the new defaults size-sensitive and post back my modified patchset when I'm done. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 6:15:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 68A7037B405 for ; Fri, 7 Dec 2001 06:15:04 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 7 Dec 2001 14:15:03 +0000 (GMT) To: Sheldon Hearn Cc: Matthew Dillon , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems In-Reply-To: Your message of "Fri, 07 Dec 2001 15:35:34 +0200." <31807.1007732134@axl.seasidesoftware.co.za> Date: Fri, 07 Dec 2001 14:15:00 +0000 From: Ian Dowse Message-ID: <200112071415.aa41493@salmon.maths.tcd.ie> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <31807.1007732134@axl.seasidesoftware.co.za>, Sheldon Hearn writes: > >The only other thing I can think of is what obrien suggested. He told >me that it might be that people are wary of a filesystem that contains >only a single cylinder group, as this means you only have one >superblock. Just to clarify, each cylinder group has one backup superblock. This is in addition to the master superblock, so on a filesystem with just one cylinder group there will be 2 superblocks. However, the first backup superblock is located immediately after the master superblock, so some of the benefits of extra superblocks (fsck sanity tests, recovery from the begininning of a disk getting overwritten) are lost when there is just one cylinder group. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 6:59:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 819BA37B417 for ; Fri, 7 Dec 2001 06:59:47 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16CMV0-0008aP-00; Fri, 07 Dec 2001 17:01:14 +0200 From: Sheldon Hearn To: Bob Bishop Cc: Kirk McKusick , freebsd-arch@FreeBSD.ORG, Matthew Dillon Subject: Re: Using a larger block size on large filesystems In-reply-to: Your message of "Fri, 07 Dec 2001 16:15:36 +0200." <32520.1007734536@axl.seasidesoftware.co.za> Date: Fri, 07 Dec 2001 17:01:14 +0200 Message-ID: <33008.1007737274@axl.seasidesoftware.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 07 Dec 2001 16:15:36 +0200, Sheldon Hearn wrote: > Okay, in that case, the threshold needs to be 196MB, from which size > upward we're guaranteed of at least one backup superblock. > > I'll get cracking on making the new defaults size-sensitive and post > back my modified patchset when I'm done. Yuk. :-( This really shouldn't be size-sensitive. It should be sensitive to the number of cylinder groups. The problem is that ncpg is calculated in mkfs.c, but we need it in newfs.c when we decide whether defaulting to 16384/2048 is going to be okay. :-( Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 8:15:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 82C3B37B405; Fri, 7 Dec 2001 08:15:28 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id fB7GE0j22767; Fri, 7 Dec 2001 17:14:00 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org, net@freebsd.org Subject: Request to back out Luigis polled-net patch in -stable. Date: Fri, 07 Dec 2001 17:14:00 +0100 Message-ID: <22765.1007741640@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ------- Forwarded Message To: core@freebsd.org Subject: Request to back out Luigis polled-net patch in -stable. From: Poul-Henning Kamp Date: Fri, 07 Dec 2001 17:13:24 +0100 Message-ID: <22749.1007741604@critter.freebsd.dk> Sender: phk@critter.freebsd.dk I have not read the entire patch in details, but have focused on the part of the code which I have special insight into. My complaint is therefore mainly based on one single file: src/sys/kern/kern_clock.c which has been spammed with a lot of stuff which has absolutely no business being there. Just for starters: Adding this to sys/kern/kern_clock.c: +#ifdef DEVICE_POLLING +#include /* for vm_page_zero_idle() */ +#include /* needed by sys/if.h */ +#include /* for IFF_* flags */ +#include /* for NETISR_POLL */ +[...] +#endif /* DEVICE_POLLING */ None of this as any business here, and it certainly doesn't even look remotely possible for this to work on !i386 platforms. Most of the rest of the addition is code which should not be in sys/kern in the first place but sys/net. Just because it is #ifdef DEVICE_POLLING doesn't mean it can violate our architecture. Furthermore, according to the commit message, this was approved by jkh in his role of release-engineer, but I find it disturbing that the approval seems to have happened without any technical or architectural review of the proposed patch. Finally, I thought a significant change like this would have to go into -current at least at the same time, but preferably before it goes into -stable. Considering the repeated claims of +10% performance for this suite of changes, there is a very good chance that people will pick it up and use it, leaving us with a big problem when 5.0-R time comes around and we have to explain A) why the feature isn't there, and B) why performance is worse. Summary: I request that luigis patch gets backed out for the following reasons: 1. The patch is architecturally a mess. 2. The approval seems to have happened purely on "glossy sales-brochure" backing without any technical or architectural input. 3. It didn't go into -current first and has received no shakeout before it went into -stable. I am _NOT_ saying that the idea is bad, it sounds pretty intelligent to me, but in that case it is even more important to not mess it up. I would also like to point to the parallel piece of code: Jun-Itohs ALTQ for which he reliably has maintained a patch relative to the 4.X branch and which despite various peoples requests have not haphazardly been committed into -stable. And in that context one should not forget that ALTQ has a lot longer and better trackrecord of high quality than Luigis poll-code, or any of Luigis code for that matter. - -- 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. ------- End of Forwarded Message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 10:22: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 678D537B41A for ; Fri, 7 Dec 2001 10:22:00 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fB7ILki45680 for ; Fri, 7 Dec 2001 13:21:46 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 7 Dec 2001 13:21:46 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org Subject: Default value for maxusers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG While reviewing and updating the content of tuning(7), I noticed the following text: The kern.maxusers tunable defaults to an incredibly low value. For most modern machines, you probably want to increase this value to 64, 128, or 256. We do not recommend going above 256 unless you need a huge number of file descriptors. Network buffers are also affected but can be controlled with a separate kernel option. Do not increase maxusers just to get more network mbufs. Systems older than FreeBSD 4.4 do not have this loader tunable and require that the kernel config(8) option maxusers be set instead. The first two sentences suggest that either we need to do one of the following: (1) Update the default maxusers value in GENERIC to something larger (perhaps 64), and remove the text from tuning(7), or... (2) Remove this text from tuning(7). It seems rediculous to have a default that is known to be inadequate (or worse, "incredibly low"). I have to admit that the first thing I do with any box is either recompile the kernel to have higher maxusers, or use kern.maxusers in /boot/loader.conf to update it to at least 64. If we believe the observations above are correct, the choice seems simple: update GENERIC, and I'd be happy to commit that to at least -CURRENT, and possibly -STABLE. If they're not, we should moderate the description above a bit :-). 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-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 10:32:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from blackhelicopters.org (geburah.blackhelicopters.org [209.69.178.18]) by hub.freebsd.org (Postfix) with ESMTP id A4D2D37B419; Fri, 7 Dec 2001 10:32:49 -0800 (PST) Received: (from mwlucas@localhost) by blackhelicopters.org (8.11.6/8.11.6) id fB7IWnc12794; Fri, 7 Dec 2001 13:32:49 -0500 (EST) (envelope-from mwlucas) Date: Fri, 7 Dec 2001 13:32:48 -0500 From: Michael Lucas To: Robert Watson Cc: arch@FreeBSD.ORG Subject: Re: Default value for maxusers Message-ID: <20011207133248.A12700@blackhelicopters.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 rwatson@FreeBSD.ORG on Fri, Dec 07, 2001 at 01:21:46PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG As a person who actually reads -questions, -stable, etc, and trolls for new FAQs: Please upsize maxusers. Please. Either GENERIC or tuning(7) should be fixed, and maxusers is too low for most of our users. 64 would be fine for most people. People running on a 386-486 will be customizing their kernels anyway. ==ml On Fri, Dec 07, 2001 at 01:21:46PM -0500, Robert Watson wrote: > > While reviewing and updating the content of tuning(7), I noticed the > following text: > > The kern.maxusers tunable defaults to an incredibly low value. For most > modern machines, you probably want to increase this value to 64, 128, or > 256. We do not recommend going above 256 unless you need a huge number > of file descriptors. Network buffers are also affected but can be > controlled with a separate kernel option. Do not increase maxusers just > to get more network mbufs. Systems older than FreeBSD 4.4 do not have > this loader tunable and require that the kernel config(8) option maxusers > be set instead. > > The first two sentences suggest that either we need to do one of the > following: > > (1) Update the default maxusers value in GENERIC to something larger > (perhaps 64), and remove the text from tuning(7), or... > > (2) Remove this text from tuning(7). > > It seems rediculous to have a default that is known to be inadequate (or > worse, "incredibly low"). I have to admit that the first thing I do with > any box is either recompile the kernel to have higher maxusers, or use > kern.maxusers in /boot/loader.conf to update it to at least 64. If we > believe the observations above are correct, the choice seems simple: > update GENERIC, and I'd be happy to commit that to at least -CURRENT, and > possibly -STABLE. If they're not, we should moderate the description > above a bit :-). > > 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-arch" in the body of the message -- Michael Lucas mwlucas@FreeBSD.org, mwlucas@blackhelicopters.org http://www.blackhelicopters.org/~mwlucas/ Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 10:43:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id AD35E37B405; Fri, 7 Dec 2001 10:43:29 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id fB7IhR145722; Fri, 7 Dec 2001 13:43:27 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Fri, 7 Dec 2001 13:43:24 -0500 To: Robert Watson , arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: Default value for maxusers Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 1:21 PM -0500 12/7/01, Robert Watson wrote: >While reviewing and updating the content of tuning(7), I noticed the >following text: > > The kern.maxusers tunable defaults to an incredibly low value. > For most modern machines, you probably want to increase this > value to 64, 128, or 256. >The first two sentences suggest that either we need to do one of the >following: > >(1) Update the default maxusers value in GENERIC to something larger > (perhaps 64), and remove the text from tuning(7), or... > >(2) Remove this text from tuning(7). > >It seems rediculous to have a default that is known to be inadequate (or >worse, "incredibly low"). Isn't this a case where GENERIC has a value set for "older, smaller" machines, so it can be used for booting up any machine? Most modern machines may want 64 or more, but what happens for older machines if we increase that value? Another thing I sometimes wonder is if that value (MAXUSERS) sets the right values for whatever it is setting. I mean, I always increase maxusers on my machines, but on the other hand most of my machines never have more than three people connected to them at any one time. Why am I setting "MAXUSERS" to 64 or 96 on a machine that only has 3 people logged in? -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 10:53:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 1ACEE37B405 for ; Fri, 7 Dec 2001 10:53:27 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fB7IrBi46120; Fri, 7 Dec 2001 13:53:11 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 7 Dec 2001 13:53:11 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Garance A Drosihn Cc: arch@FreeBSD.ORG Subject: Re: Default value for maxusers In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 7 Dec 2001, Garance A Drosihn wrote: > Isn't this a case where GENERIC has a value set for "older, smaller" > machines, so it can be used for booting up any machine? Most modern > machines may want 64 or more, but what happens for older machines if we > increase that value? Quite possibly. On the other hand, we've started to trim some older hardware support from GENERIC over time: in the last few months, we've dropped i386, and emulated math coprocessors. We've also gradually bumped up the memory requirements (I remember it going to 5, but it's probably to 8 now). I guess a useful question might be: what is the memory cost/footprint per "user" in maxusers. If we assume boxes today ship with a minimum of 64mb, and more likely 128mb, we can tune it appropriately. > Another thing I sometimes wonder is if that value (MAXUSERS) sets the > right values for whatever it is setting. I mean, I always increase > maxusers on my machines, but on the other hand most of my machines never > have more than three people connected to them at any one time. Why am I > setting "MAXUSERS" to 64 or 96 on a machine that only has 3 people > logged in? Dunno. It may be that "maxusers" is simply an out-dated term, and we should break it down into its components, seperately tweakable at boot-time using loader.conf. Many sites already seperately define NMBCLUSTERS to optimize network behavior independently from maxusers and the tables it implies. 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-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 11:13:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from beastie.mckusick.com (tserver.conference.usenix.org [209.179.127.3]) by hub.freebsd.org (Postfix) with ESMTP id 8C31537B405 for ; Fri, 7 Dec 2001 11:13:21 -0800 (PST) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.11.4/8.9.3) with ESMTP id fB7JCvf29494; Fri, 7 Dec 2001 11:13:04 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200112071913.fB7JCvf29494@beastie.mckusick.com> To: Sheldon Hearn Subject: Re: Using a larger block size on large filesystems Cc: freebsd-arch@FreeBSD.ORG In-Reply-To: Your message of "Fri, 07 Dec 2001 13:44:36 GMT." <4.3.2.7.2.20011207134031.00bbfc40@gid.co.uk> Date: Fri, 07 Dec 2001 11:12:57 -0800 From: Kirk McKusick Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Even with only one cylinder group you will have two superblocks. One in the standard location (at sectors 16-32) and one backup in the first cylinder group (at sectors 32-48). The down side is that they immediately follow each other, but there are two copies. The main drawback of 16K/2K for small filsystems that I see is the wasted space (rounding up to 2K rather than 1K) means that you will fill it up faster than you would with 8K/1K. On balance, I do not see either of these as strong enough reasons to special case `small' filsystems though I would not object if you choose to do so. FYA, we had this same debate a bit over a decade ago when we changed the default from 4K/512 to 8K/1K. Obviously, we decided not to special case small filesystems then despite great hand-wringing over what would happen... Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 11:14:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from technokratis.com (modemcable099.144-201-24.mtl.mc.videotron.ca [24.201.144.99]) by hub.freebsd.org (Postfix) with ESMTP id 9803D37B416; Fri, 7 Dec 2001 11:14:24 -0800 (PST) Received: (from bmilekic@localhost) by technokratis.com (8.11.4/8.11.3) id fB7JFou44031; Fri, 7 Dec 2001 14:15:50 -0500 (EST) (envelope-from bmilekic) Date: Fri, 7 Dec 2001 14:15:50 -0500 From: Bosko Milekic To: Robert Watson Cc: arch@FreeBSD.ORG Subject: Re: Default value for maxusers Message-ID: <20011207141550.A43932@technokratis.com> 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 rwatson@FreeBSD.ORG on Fri, Dec 07, 2001 at 01:21:46PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Dec 07, 2001 at 01:21:46PM -0500, Robert Watson wrote: > > While reviewing and updating the content of tuning(7), I noticed the > following text: > > The kern.maxusers tunable defaults to an incredibly low value. For most > modern machines, you probably want to increase this value to 64, 128, or Suggestion: increase maxusers, strike those two lines. Replace with something like: The kern.maxusers tunable is used to scale a variety of resource parameters in the kernel. It is used to determine, possibly amongst other things, the virtual address space allocated to network memory buffers, the number of file descriptors, and the maximum number of processes. The default value is . We do not recommend... [continue original text below]... > 256. We do not recommend going above 256 unless you need a huge number > of file descriptors. Network buffers are also affected but can be > controlled with a separate kernel option. Do not increase maxusers just ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I would also add, in parantheses (NMBCLUSTERS). > to get more network mbufs. Systems older than FreeBSD 4.4 do not have > this loader tunable and require that the kernel config(8) option maxusers > be set instead. Suggestion: Leave this text, it is still relevant. > The first two sentences suggest that either we need to do one of the > following: > > (1) Update the default maxusers value in GENERIC to something larger > (perhaps 64), and remove the text from tuning(7), or... > > (2) Remove this text from tuning(7). > > It seems rediculous to have a default that is known to be inadequate (or > worse, "incredibly low"). I have to admit that the first thing I do with > any box is either recompile the kernel to have higher maxusers, or use > kern.maxusers in /boot/loader.conf to update it to at least 64. If we > believe the observations above are correct, the choice seems simple: > update GENERIC, and I'd be happy to commit that to at least -CURRENT, and > possibly -STABLE. If they're not, we should moderate the description > above a bit :-). > > Robert N M Watson FreeBSD Core Team, TrustedBSD Project > robert@fledge.watson.org NAI Labs, Safeport Network Services -- Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 11:21:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 6559E37B405; Fri, 7 Dec 2001 11:21:53 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fB7JQx301437; Fri, 7 Dec 2001 11:26:59 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112071926.fB7JQx301437@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Poul-Henning Kamp Cc: arch@freebsd.org, net@freebsd.org Subject: Re: Request to back out Luigis polled-net patch in -stable. In-reply-to: Your message of "Fri, 07 Dec 2001 17:14:00 +0100." <22765.1007741640@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Dec 2001 11:26:59 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > To: core@freebsd.org Core isn't really the appropriate forum for asking for a back-out; arch and net are where this should have been discussed and reviewed in the first place. > Subject: Request to back out Luigis polled-net patch in -stable. I'm entirely in agreement with this; the decision to commit this code was extremely ill-advised, and the best thing we can do now for everyone's sake is to pull it as quickly as possible. > I would also like to point to the parallel piece of code: Jun-Itohs > ALTQ for which he reliably has maintained a patch relative to the > 4.X branch and which despite various peoples requests have not > haphazardly been committed into -stable. And in that context one > should not forget that ALTQ has a lot longer and better trackrecord > of high quality than Luigis poll-code, or any of Luigis code for > that matter. Yes; this is an excellent example of how it can be done better. Regards, Mike -- ... 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-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 11:39:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 6ED1037B41A; Fri, 7 Dec 2001 11:39:09 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id fB7Jd51100684; Fri, 7 Dec 2001 14:39:05 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Fri, 7 Dec 2001 14:39:02 -0500 To: Robert Watson From: Garance A Drosihn Subject: Re: Default value for maxusers Cc: arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 1:53 PM -0500 12/7/01, Robert Watson wrote: >On Fri, 7 Dec 2001, Garance A Drosihn wrote: > >> Isn't this a case where GENERIC has a value set for "older, smaller" >> machines, so it can be used for booting up any machine? Most modern > > machines may want 64 or more, but what happens for older machines > > if we increase that value? > >Quite possibly. On the other hand, we've started to trim some older >hardware support from GENERIC over time: in the last few months, we've >dropped i386, and emulated math coprocessors. By the way, I didn't explicitly state it in my previous message, but it does seem reasonable to *me* (with my machines) that the default value should be raised, one way or another. I just don't know how raising it would effect others. Maybe raise it to some midpoint between 32 and 64? Maybe 40 or 48? The result does not have to be great on older hardware, but I do think it should be "bootable". > > Another thing I sometimes wonder is if that value (MAXUSERS) sets > > the right values for whatever it is setting. I mean, I always > > increase maxusers on my machines, but on the other hand most of my > > machines never have more than three people connected to them at > > any one time. > >Dunno. It may be that "maxusers" is simply an out-dated term, and >we should break it down into its components, seperately tweakable at >boot-time using loader.conf. Many sites already seperately define >NMBCLUSTERS to optimize network behavior independently from maxusers >and the tables it implies. Well, "maxusers" sounds like a user-friendly measurement, in the sense that it's a question that any person might feel comfortable guessing at. If we remove that setting, then people have to guess at how many NMBCLUSTERS that they need. I dread installing things which ask me questions where I don't even know what the question means, never mind what the right answer is... I'm thinking more that maybe the mapping between the MAXUSERS value and should be different. So, we would not change the default value for MAXUSERS, but we would change how many NMBCLUSTERS are assigned per MAXUSER, and thus a default setting of 32 be reasonable for many of the machines which run freebsd. I guess the first question is "what *does* maxusers effect?", and then out of that list, which of those values are "incredibly low" for the default installation? In some sense, I would actually prefer if the actual default value for MAXUSERS was *lower* (say 16), and but that the things which key off that value were changed such that MAXUSERS=16 has the *effect* of what is now meant by (say) MAXUSERS=48. On the other hand, maybe it's less confusing to just increase the value of MAXUSERS and stick with the same mapping... :-) -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 11:57: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 6D71737B405; Fri, 7 Dec 2001 11:57:05 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id fB7JuwY90155; Fri, 7 Dec 2001 11:56:58 -0800 (PST) (envelope-from obrien) Date: Fri, 7 Dec 2001 11:56:58 -0800 From: "David O'Brien" To: Garance A Drosihn Cc: Robert Watson , arch@FreeBSD.ORG Subject: Re: Default value for maxusers Message-ID: <20011207115658.A82602@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG Mail-Followup-To: arch@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 drosih@rpi.edu on Fri, Dec 07, 2001 at 02:39:02PM -0500 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Dec 07, 2001 at 02:39:02PM -0500, Garance A Drosihn wrote: > I'm thinking more that maybe the mapping between the MAXUSERS value > and should be different. I think *this* is the key issue. MAXUSERS is just simply bogus today. Change it to MAXXTERMS or something else that would actually cause people to pick the right setting. MAXUSERS=2 on my desktop with 1GB RAM certainly isn't an intelegent setting, but `2' is the answer to MAXUSERS for this machine. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 11:57:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from beastie.mckusick.com (tserver.conference.usenix.org [209.179.127.3]) by hub.freebsd.org (Postfix) with ESMTP id DCF6137B416; Fri, 7 Dec 2001 11:57:39 -0800 (PST) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.11.4/8.9.3) with ESMTP id fB7Jvef29774; Fri, 7 Dec 2001 11:57:41 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200112071957.fB7Jvef29774@beastie.mckusick.com> To: Robert Watson Subject: Re: Default value for maxusers Cc: arch@FreeBSD.ORG In-Reply-To: Your message of "Fri, 07 Dec 2001 13:53:11 EST." Date: Fri, 07 Dec 2001 11:57:40 -0800 From: Kirk McKusick Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I believe that we should do what BSD/OS did years ago. They default maxusers to 0 which tells the system to size it at boot time based on the amount of memory available on the system. Small memory machines end up with a small value of maxusers and large memory machines ends up with a large value of maxusers. In the rare case where the default is wrong, the system administrator can set it to some non-zero value which the kernel then uses. We created maxusers so there would be one big knob that can be used to set the many internal values needed by the system. It will never be perfect, and where changes are needed (more mbufs for example), the system administrator can adjust the individual knobs as needed. But we should still have the big knob. As for the name, it is not ideal, but no other clearly better ones come to mind, and maxusers is a well known name by the legions of folks that actually have to set up BSD systems. So, absent a compelling new name, I vote to keep the name that people know. Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 12:11:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 715CB37B405; Fri, 7 Dec 2001 12:11:57 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id fB7KBrj10922; Fri, 7 Dec 2001 12:11:53 -0800 (PST) (envelope-from obrien) Date: Fri, 7 Dec 2001 12:11:53 -0800 From: "David O'Brien" To: John Baldwin Cc: Diane Bruce , tobez@FreeBSD.org, arch@FreeBSD.org, Sean Chittenden Subject: Re: Perl 5.6.1 in the base.... Message-ID: <20011207121153.D82602@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <200112062305.fB6N5xt17790@mtbaker.tfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Thu, Dec 06, 2001 at 04:28:27PM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Dec 06, 2001 at 04:28:27PM -0800, John Baldwin wrote: > > More like its time to remove perl altogether from the base. > > Unfortunately the kernel build needs it. Not for too much longer. db has written all but ?1? of the scripts in C. I just need to test and commit them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 12:13:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 8843E37B405 for ; Fri, 7 Dec 2001 12:13:40 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id fB7KDSh12084; Fri, 7 Dec 2001 12:13:28 -0800 (PST) (envelope-from obrien) Date: Fri, 7 Dec 2001 12:13:28 -0800 From: "David O'Brien" To: Josef Karthauser Cc: arch@FreeBSD.ORG Subject: Re: Perl 5.6.1 in the base.... Message-ID: <20011207121328.E82602@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20011207020751.29B40380D@overcee.netplex.com.au> <20011207092516.GA20217@clk.cirx.org> <20011207124312.B76875@tao.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011207124312.B76875@tao.org.uk>; from joe@tao.org.uk on Fri, Dec 07, 2001 at 12:43:12PM +0000 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Dec 07, 2001 at 12:43:12PM +0000, Josef Karthauser wrote: > On Fri, Dec 07, 2001 at 05:25:16PM +0800, Chia-liang Kao wrote: > > In a private mail conversation with tobez back several months ago, he > > mentioned he'll do the import soon. So I guess he signed up for this. > > > > I would really like to see -current to have 5.7.2 since 5.8.0 is > > coming, while -stable to have 5.6.1 as it had been proven quite > > stable. It'd also be nice to bring tobez's wonderful BSDPAN to -stable > > along with perl 5.6.1 > > This is pending on some other packages issues. Which ARE??? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 12:15:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from prism.flugsvamp.com (66-188-92-95.mad.wi.charter.com [66.188.92.95]) by hub.freebsd.org (Postfix) with ESMTP id 5EDCF37B417; Fri, 7 Dec 2001 12:15:14 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.6/8.11.6) id fB7KF3G31999; Fri, 7 Dec 2001 14:15:03 -0600 (CST) (envelope-from jlemon) Date: Fri, 7 Dec 2001 14:15:03 -0600 From: Jonathan Lemon To: "David O'Brien" Cc: John Baldwin , Diane Bruce , tobez@FreeBSD.ORG, arch@FreeBSD.ORG, Sean Chittenden Subject: Re: Perl 5.6.1 in the base.... Message-ID: <20011207141503.A377@prism.flugsvamp.com> References: <200112062305.fB6N5xt17790@mtbaker.tfm.com> <20011207121153.D82602@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20011207121153.D82602@dragon.nuxi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Dec 07, 2001 at 12:11:53PM -0800, David O'Brien wrote: > On Thu, Dec 06, 2001 at 04:28:27PM -0800, John Baldwin wrote: > > > More like its time to remove perl altogether from the base. > > > > Unfortunately the kernel build needs it. > > Not for too much longer. db has written all but ?1? of the scripts in C. > I just need to test and commit them. Can't we coerce her into becoming a committer? :-) -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 12:44:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from inje.iskon.hr (inje.iskon.hr [213.191.128.16]) by hub.freebsd.org (Postfix) with ESMTP id 8360B37B41C; Fri, 7 Dec 2001 12:44:25 -0800 (PST) Received: from tel.fer.hr (zg07-209.dialin.iskon.hr [213.191.150.210]) by mail.iskon.hr (8.11.4/8.11.4/Iskon 8.11.3-1) with ESMTP id fB7Ki9O17119; Fri, 7 Dec 2001 21:44:12 +0100 (MET) Message-ID: <3C112A14.21F08D50@tel.fer.hr> Date: Fri, 07 Dec 2001 21:44:04 +0100 From: Marko Zec X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Smith Cc: Poul-Henning Kamp , arch@freebsd.org, net@freebsd.org Subject: Re: Request to back out Luigis polled-net patch in -stable. References: <200112071926.fB7JQx301437@mass.dis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Smith wrote: > > Subject: Request to back out Luigis polled-net patch in -stable. > > I'm entirely in agreement with this; the decision to commit this code was > extremely ill-advised, and the best thing we can do now for everyone's > sake is to pull it as quickly as possible. > > > I would also like to point to the parallel piece of code: Jun-Itohs > > ALTQ for which he reliably has maintained a patch relative to the > > 4.X branch and which despite various peoples requests have not > > haphazardly been committed into -stable. And in that context one > > should not forget that ALTQ has a lot longer and better trackrecord > > of high quality than Luigis poll-code, or any of Luigis code for > > that matter. > > Yes; this is an excellent example of how it can be done better. Sorry guys, but aren't you comparing apples with oranges? As far as I understand, ALTQ is focused on implementing various new queuing disciplines, but on outgoing traffic if I am not mistaking. Luigi's code is aimed on achieving something completely different - making the system more susceptible to huge *incoming* traffic loads, by reducing interrupt processing and some PCI bus overhead. What do these two things have in common? Concerning the request for removal of the polling code, I personally as a BSD rookie cannot judge your arguments properly, but I must admit that the wording and intonation of pkh's note wasn't very pleasant... Marko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 13:50:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 3DEF437B405; Fri, 7 Dec 2001 13:50:49 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id fB7Lns1135628; Fri, 7 Dec 2001 16:49:54 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <3C112A14.21F08D50@tel.fer.hr> References: <200112071926.fB7JQx301437@mass.dis.org> <3C112A14.21F08D50@tel.fer.hr> Date: Fri, 7 Dec 2001 16:49:51 -0500 To: Marko Zec , Mike Smith From: Garance A Drosihn Subject: Re: Request to back out Luigis polled-net patch in -stable. Cc: Poul-Henning Kamp , arch@FreeBSD.ORG, net@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 9:44 PM +0100 12/7/01, Marko Zec wrote: >Mike Smith wrote: > > > I would also like to point to the parallel piece of code: Jun-Itohs >> > ALTQ for which he reliably has maintained a patch relative to the >> > 4.X branch and which despite various peoples requests have not > > > haphazardly been committed into -stable. > > >> Yes; this is an excellent example of how it can be done better. > >Sorry guys, but aren't you comparing apples with oranges? They are comparing how two changes were made. Not what the changes actually *do*, but the path the changes took to get into -stable. In that sense, they are not comparing apples to oranges. They are comparing the conveyor belts under the apples vs the conveyor belts the oranges were allowed to use. >Concerning the request for removal of the polling code, I personally >as a BSD rookie cannot judge your arguments properly, but I must >admit that the wording and intonation of pkh's note wasn't very >pleasant... Poul-Henning included one comment about "track records" which may have been a bit harsh, but if you ignore that one sentence than everything he said seemed pretty reasoned (ie, "calmly thought out", as opposed to "emotional outburst"), and pretty reasonable. I think PHK and Mike Smith have made a pretty good case, but I will admit that I don't know all of the issues involved. I suspect the other side of this debate is that Luigi's change is meant for high-load situations, and very very very few people are running a 5.0-current system in those kinds of high-load situations. I can see that being a good reason to put it in stable, but even with this good reason, I think it might be better to back the change out of stable until AFTER 4.5 is released. This change did not go thru the "normal routine" for changes, and as such I do think any developer has the right to make a case that the change should be backed out. I *like* what the change is trying to do, and the methods it is using certainly sound interesting. But I don't think it would hurt to have it looked over a bit more before committing it to -stable. That's just my opinion, as I watch this debate from the sidelines. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 14:37:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id BF14837B41A; Fri, 7 Dec 2001 14:37:05 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id fB7MZHj30558; Fri, 7 Dec 2001 23:35:17 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Garance A Drosihn Cc: Marko Zec , Mike Smith , arch@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Request to back out Luigis polled-net patch in -stable. In-Reply-To: Your message of "Fri, 07 Dec 2001 16:49:51 EST." Date: Fri, 07 Dec 2001 23:35:17 +0100 Message-ID: <30556.1007764517@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Garance A Drosihn writes: >Poul-Henning included one comment about "track records" which may >have been a bit harsh, but if you ignore that one sentence than >everything he said seemed pretty reasoned (ie, "calmly thought out", >as opposed to "emotional outburst"), and pretty reasonable. I would like to defend that comment, and I apologize for it sounding harsh, it was simply meant as a flat statement of fact on my part. We have committers in the project who gets things right the first time around, every time, on time, on schedule, under budget and with a global reduction of green-house gasses as a side effect. When Bruce Evans commits something one can virtually rest assured that it has been throughly tested ever since he originally wrote it in 1974 and that several satelites and ICBMs wouldn't work and the cold war would not have ended without that patch. Then we have other committers who drag a trail of death and destruction through a sequence of more and more frantic commits until they finally (by accident ?) gets it right enough that the tree isn't broken anymore. (I wont mention names here). These are the two extremes, between them you will find the rest of us. Now, for something to go into -stable, there are certain standards, we have haggled over them from time to time. For a new feature to go into -stable, there has to be very very good reasons not to take the detour around -current. In particular there has to be a very good and convincing argument that something _will_ go into -current, so that we don't introduce a feature in -stable which the next major release will simply not have: We don't need to disappoint our users any more than we need to with our major releases. Luigi has a track record of delivering some very smart code to FreeBSD, I'm a big fan of his IPFW and DUMMYNET stuff, and I far prefer them to IPFILTER. I even think Luigi is a great guy, and I'm happy to see him being a "Professor of FreeBSD Networking" (well, not quite but...) at his University in Italy. But that doesn't change the fact that Luigis code has never been a "working first time thing wihtout a hitch" for us. There has always been some issues to work out, some things to move around a bit, things which need a bit of generalization and so on. In other words: Luigi is a perfectly normal FreeBSD committer. And that means that he should follow the rules we have for -stable: he doesn't clear the bar to cold commit a new feature into -stable. In particular it should not when it is not convincingly argued that we will be able to integrate the new features in -current any time soon. That's all. I'm not against his code, I just don't want it to go straight into -stable. If the argument holds that -stable and -current has diverged too much for it being feasible to go the usual "into -current, then MFC" walk, then we need to reexamine the entire "-current/-stable" setup and maybe add a 4-CURRENT development-branch from which things get merged to 4-STABLE. (Having worked in multi-branch environments like that, I would be strongly against any such thing and I think anyone who has tried to navigate the cisco IOS version maelström in recent years are likely to be against as well). So in summary my position is: Luigi stuff should be backed out of -stable. Luigi should figure out how to do this right in SMPng/-current and implement it there. Then when we have some experience with it, we can decide on a rational basis if it should be MFC'ed, (or committed cold into -stable if the MFC doesn't make sense). And of course Luigi is more than welcome to distribute his change as a patch against -stable, just like Jun-Itoh does with his ALTQ. (I don't know if Peter has -stable in P4, but that could be one way to make it easier for Luigi to maintain the patch if he had a branch there) -- 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-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 14:57:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id E45B937B416 for ; Fri, 7 Dec 2001 14:57:45 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB7MvjE95211; Fri, 7 Dec 2001 14:57:45 -0800 (PST) (envelope-from dillon) Date: Fri, 7 Dec 2001 14:57:45 -0800 (PST) From: Matthew Dillon Message-Id: <200112072257.fB7MvjE95211@apollo.backplane.com> To: Sheldon Hearn Cc: Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems References: <31807.1007732134@axl.seasidesoftware.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :Hi Matt, : :I already have patches for newfs, sysinstall and the tuning(7) manual :page which simply make 16384/2048 the default. : :However, I remember people expressing concerns with using these parameters :for very small filesystems. : :I can't find any negative performance impact for very small filesystems. : :The only other thing I can think of is what obrien suggested. He told :me that it might be that people are wary of a filesystem that contains :only a single cylinder group, as this means you only have one :superblock. : :Is this really something to worry about? Is there some other reason why :we shouldn't just make 16384/2048 the blanket default? : :Ciao, :Sheldon. I think you've hit the nail on the head. I think we do want at least two cylinder groups, but beyond that I think even the smallest hard drive will do just fine with 16K/2K. Floppies and other types of media are already hardwired in /etc/disktab so we shouldn't have to worry about them. In considering Kirk's posting in regards to the 512/4K -> 1K/8K debate, I think we are in exactly the same situation here and should just maintain a stiff upper lip and change the default to 2K/16K. People with 'special' requirements are smart enough to manage the parameters themselves. 2K/16K is a good default for more of our users then 1K/8K was. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 15:11:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 5728937B416 for ; Fri, 7 Dec 2001 15:11:11 -0800 (PST) Received: from whizzo.transsys.com (#6@localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.6/8.11.6) with ESMTP id fB7NB2723789; Fri, 7 Dec 2001 18:11:02 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200112072311.fB7NB2723789@whizzo.transsys.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Matthew Dillon Cc: Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: Using a larger block size on large filesystems References: <31807.1007732134@axl.seasidesoftware.co.za> <200112072257.fB7MvjE95211@apollo.backplane.com> In-reply-to: Your message of "Fri, 07 Dec 2001 14:57:45 PST." <200112072257.fB7MvjE95211@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Dec 2001 18:11:02 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG While we're gonna be changing the default file system characteristics, how about having sysinstall create a reasonable size root file system for today's disks? I think that if we're installing on a multi-gigabyte disk, a 200MB root file system isn't imposing very much. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 15:25:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 1F07F37B416 for ; Fri, 7 Dec 2001 15:25:13 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB7NPBl95329; Fri, 7 Dec 2001 15:25:11 -0800 (PST) (envelope-from dillon) Date: Fri, 7 Dec 2001 15:25:11 -0800 (PST) From: Matthew Dillon Message-Id: <200112072325.fB7NPBl95329@apollo.backplane.com> To: "Louis A. Mamakos" Cc: Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems References: <31807.1007732134@axl.seasidesoftware.co.za> <200112072257.fB7MvjE95211@apollo.backplane.com> <200112072311.fB7NB2723789@whizzo.transsys.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : : :While we're gonna be changing the default file system characteristics, :how about having sysinstall create a reasonable size root file system :for today's disks? I think that if we're installing on a multi-gigabyte :disk, a 200MB root file system isn't imposing very much. : :louie I talked with Jordan about doing this a few months ago and he essentially gave the O.K. (I think his exact words were 'go do it', but he tends to say that whenever anyone asks for a new feature in sysinstall). In any case, I think it's time has come. I'll rework the sysinstall stuff today and put it up for comment. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 15:26: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from inje.iskon.hr (inje.iskon.hr [213.191.128.16]) by hub.freebsd.org (Postfix) with ESMTP id 3831037B416 for ; Fri, 7 Dec 2001 15:25:57 -0800 (PST) Received: from tel.fer.hr (zg06-179.dialin.iskon.hr [213.191.148.180]) by mail.iskon.hr (8.11.4/8.11.4/Iskon 8.11.3-1) with ESMTP id fB7NPQO17105; Sat, 8 Dec 2001 00:25:27 +0100 (MET) Message-ID: <3C114FDF.138E09A7@tel.fer.hr> Date: Sat, 08 Dec 2001 00:25:19 +0100 From: Marko Zec X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Louis A. Mamakos" Cc: Matthew Dillon , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems References: <31807.1007732134@axl.seasidesoftware.co.za> <200112072257.fB7MvjE95211@apollo.backplane.com> <200112072311.fB7NB2723789@whizzo.transsys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Louis A. Mamakos" wrote: > While we're gonna be changing the default file system characteristics, > how about having sysinstall create a reasonable size root file system > for today's disks? I think that if we're installing on a multi-gigabyte > disk, a 200MB root file system isn't imposing very much. Why would we want to do that? Putting unnecessary things on / is always a bad idea, as root partition should remain small and as free of frequent RW operations as possible. I would prefeer to see /tmp extracted from root fs (as a mfs by default), much more than seing a huge / with lots of garbage in it. Root should remain compact as it is more or less right now. Marko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 15:30:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by hub.freebsd.org (Postfix) with ESMTP id 35B4337B416 for ; Fri, 7 Dec 2001 15:30:25 -0800 (PST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.6/8.11.6) id fB7NTwY43199; Sat, 8 Dec 2001 00:29:58 +0100 (CET) (envelope-from wkb) Date: Sat, 8 Dec 2001 00:29:58 +0100 From: Wilko Bulte To: Marko Zec Cc: "Louis A. Mamakos" , Matthew Dillon , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems Message-ID: <20011208002958.A43171@freebie.xs4all.nl> References: <31807.1007732134@axl.seasidesoftware.co.za> <200112072257.fB7MvjE95211@apollo.backplane.com> <200112072311.fB7NB2723789@whizzo.transsys.com> <3C114FDF.138E09A7@tel.fer.hr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C114FDF.138E09A7@tel.fer.hr>; from zec@tel.fer.hr on Sat, Dec 08, 2001 at 12:25:19AM +0100 X-OS: FreeBSD 4.4-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Dec 08, 2001 at 12:25:19AM +0100, Marko Zec wrote: > "Louis A. Mamakos" wrote: > > > While we're gonna be changing the default file system characteristics, > > how about having sysinstall create a reasonable size root file system > > for today's disks? I think that if we're installing on a multi-gigabyte > > disk, a 200MB root file system isn't imposing very much. > > Why would we want to do that? Putting unnecessary things on / is always a > bad idea, as root partition should remain small and as free of frequent RW > operations as possible. I would prefeer to see /tmp extracted from root fs > (as a mfs by default), much more than seing a huge / with lots of garbage in > it. Root should remain compact as it is more or less right now. One reason: as releases progress the default of the older releases has bitten me more than once. Meaning / was too small. Really funny (not) during an upgrade.. Compact is OK, just make sure it isn't too compact ;) W/ -- | / o / /_ _ email: wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 15:31:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id F25D337B507 for ; Fri, 7 Dec 2001 15:31:36 -0800 (PST) Received: from whizzo.transsys.com (#6@localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.6/8.11.6) with ESMTP id fB7NVM724075; Fri, 7 Dec 2001 18:31:22 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200112072331.fB7NVM724075@whizzo.transsys.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Marko Zec Cc: Matthew Dillon , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: Using a larger block size on large filesystems References: <31807.1007732134@axl.seasidesoftware.co.za> <200112072257.fB7MvjE95211@apollo.backplane.com> <200112072311.fB7NB2723789@whizzo.transsys.com> <3C114FDF.138E09A7@tel.fer.hr> In-reply-to: Your message of "Sat, 08 Dec 2001 00:25:19 +0100." <3C114FDF.138E09A7@tel.fer.hr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Dec 2001 18:31:22 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > "Louis A. Mamakos" wrote: > > > While we're gonna be changing the default file system characteristics, > > how about having sysinstall create a reasonable size root file system > > for today's disks? I think that if we're installing on a multi-gigabyte > > disk, a 200MB root file system isn't imposing very much. > > Why would we want to do that? Putting unnecessary things on / is always a > bad idea, as root partition should remain small and as free of frequent RW > operations as possible. I would prefeer to see /tmp extracted from root fs > (as a mfs by default), much more than seing a huge / with lots of garbage in > it. Root should remain compact as it is more or less right now. > > Marko I'm not gonna argue that more stuff ought to be put on the root file system, but having more breathing room also fixes the "running out of space when installing a new kernel due to softupdates" problem. Or having space more an extra backup kernel (and modules) without worrying how close to full you are. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 15:54:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from inje.iskon.hr (inje.iskon.hr [213.191.128.16]) by hub.freebsd.org (Postfix) with ESMTP id 2181E37B416 for ; Fri, 7 Dec 2001 15:54:40 -0800 (PST) Received: from tel.fer.hr (zg03-069.dialin.iskon.hr [213.191.135.70]) by mail.iskon.hr (8.11.4/8.11.4/Iskon 8.11.3-1) with ESMTP id fB7NsWO25951; Sat, 8 Dec 2001 00:54:32 +0100 (MET) Message-ID: <3C1156B1.F44F844B@tel.fer.hr> Date: Sat, 08 Dec 2001 00:54:25 +0100 From: Marko Zec X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Louis A. Mamakos" Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems References: <31807.1007732134@axl.seasidesoftware.co.za> <200112072257.fB7MvjE95211@apollo.backplane.com> <200112072311.fB7NB2723789@whizzo.transsys.com> <3C114FDF.138E09A7@tel.fer.hr> <200112072331.fB7NVM724075@whizzo.transsys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Louis A. Mamakos" wrote: > I'm not gonna argue that more stuff ought to be put on the root file > system, but having more breathing room also fixes the "running out of > space when installing a new kernel due to softupdates" problem. Or > having space more an extra backup kernel (and modules) without worrying > how close to full you are. My point is if we all get used to seeing huge amounts of free space in /, then we'll all be tempted to fill it up sooner or later with necessary or unnecessary stuff. And then we can go into another cycle of / size expansion, and so on. Right now my 4.4-R / uses 30M of space with a spare kernel image included, and I am not feeling comfortable seeing it enlarged by an order of magnitude in the next release. Those guys doing heavy development and needing multiple kernel/module trees will anyhow make a custom partitioning, and for all other people a compact sized / should be enough. Of course with /tmp extracted :) Marko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 16:32:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id B5C5837B416; Fri, 7 Dec 2001 16:32:17 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fB80b8304059; Fri, 7 Dec 2001 16:37:13 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112080037.fB80b8304059@mass.dis.org> To: Marko Zec Cc: Poul-Henning Kamp , arch@freebsd.org, net@freebsd.org Subject: Re: Request to back out Luigis polled-net patch in -stable. In-Reply-To: Message from Marko Zec of "Fri, 07 Dec 2001 21:44:04 +0100." <3C112A14.21F08D50@tel.fer.hr> Date: Fri, 07 Dec 2001 16:37:08 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > I would also like to point to the parallel piece of code: Jun-Itohs > > > ALTQ for which he reliably has maintained a patch relative to the ... > > Yes; this is an excellent example of how it can be done better. > > Sorry guys, but aren't you comparing apples with oranges? As far as I No. The issue at hand is procedure, not functionality. ALTQ is maintained and developed in a fashion consistent with the Project's general procedures and preferences. Luigi's code commit was not. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 18:27: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 74EE537B405; Fri, 7 Dec 2001 18:27:00 -0800 (PST) Received: from dialup-209.245.130.204.dial1.sanjose1.level3.net ([209.245.130.204] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16CXCd-0004Vn-00; Fri, 07 Dec 2001 18:26:59 -0800 Message-ID: <3C117A7B.C58E1654@mindspring.com> Date: Fri, 07 Dec 2001 18:27:07 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Watson Cc: arch@FreeBSD.org Subject: Re: Default value for maxusers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Robert Watson wrote: > > While reviewing and updating the content of tuning(7), I noticed the > following text: > > The kern.maxusers tunable defaults to an incredibly low value. For most > modern machines, you probably want to increase this value to 64, 128, or > 256. [ ... ] > The first two sentences suggest that either we need to do one of the > following: > > (1) Update the default maxusers value in GENERIC to something larger > (perhaps 64), and remove the text from tuning(7), or... > > (2) Remove this text from tuning(7). You need to look at the code, and not just trust the tuning page. There are plenty of things that are based on the compilation time math that occurs, which will not change, should you modify the value using this tuning variable. In addition, there are things bound together that should not be; for example, the number of UDP and TCP connection reserves for pcb's for both protocols, which I broke apart with a patch posted to -current about 4 months ago. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 18:30:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 711DB37B419 for ; Fri, 7 Dec 2001 18:30:13 -0800 (PST) Received: from dialup-209.245.130.204.dial1.sanjose1.level3.net ([209.245.130.204] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16CXFW-0007bR-00; Fri, 07 Dec 2001 18:29:59 -0800 Message-ID: <3C117B2E.233D704D@mindspring.com> Date: Fri, 07 Dec 2001 18:30:06 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kirk McKusick Cc: Sheldon Hearn , freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems References: <200112071913.fB7JCvf29494@beastie.mckusick.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Kirk McKusick wrote: > On balance, I do not see either of these as strong enough reasons > to special case `small' filsystems though I would not object if > you choose to do so. FYA, we had this same debate a bit over a > decade ago when we changed the default from 4K/512 to 8K/1K. > Obviously, we decided not to special case small filesystems > then despite great hand-wringing over what would happen... The problem now is that people are trying to redefine "small" as large enough that this is going to bite someone... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 18:52:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 1368B37B417 for ; Fri, 7 Dec 2001 18:52:24 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fB82pti58681; Fri, 7 Dec 2001 21:51:55 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 7 Dec 2001 21:51:54 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Matthew Dillon Cc: "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems In-Reply-To: <200112072325.fB7NPBl95329@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 7 Dec 2001, Matthew Dillon wrote: > :While we're gonna be changing the default file system characteristics, > :how about having sysinstall create a reasonable size root file system > :for today's disks? I think that if we're installing on a multi-gigabyte > :disk, a 200MB root file system isn't imposing very much. > > I talked with Jordan about doing this a few months ago and he > essentially gave the O.K. (I think his exact words were 'go do it', > but he tends to say that whenever anyone asks for a new feature in > sysinstall). > > In any case, I think it's time has come. I'll rework the sysinstall > stuff today and put it up for comment. While we can discuss the merits of doing this for the -STABLE branch, I for one will be quite happy to see this be the case for -CURRENT, where storing three complete sets of kernels and modules (kernel.new, kernel.old, and kernel.dontworryaboutmeiamsafe) consumes vast amounts of disk space with the various debugging symbols, et al. BTW, we keep suggesting people would be foolish to use anything other than MFS/md for /tmp (and maybe other variations on tmp), but our sysinstall doesn't support doing this "automagically". I'm not sure what the right vehicle is for that in sysinstall, but it would be nice to see. Another interesting problem with the current partition layout is the extremely small size of /var, on which we find /var/tmp, which is used for package unpacking before installation. For large packages, such as KDE, LaTeX, and friends, this can be a big problem, as well as for vmware which likes to drop huge paging files into /var/tmp. Combining these various temporary spaces into a single md partition sized to something appropriate might make sense. This is seperate issue from the root partition, of course, but something we might want to look into a strateg for. 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-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 19:31:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 2562937B417 for ; Fri, 7 Dec 2001 19:31:20 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id fB83VC1121226; Fri, 7 Dec 2001 22:31:12 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200112072311.fB7NB2723789@whizzo.transsys.com> References: <31807.1007732134@axl.seasidesoftware.co.za> <200112072257.fB7MvjE95211@apollo.backplane.com> <200112072311.fB7NB2723789@whizzo.transsys.com> Date: Fri, 7 Dec 2001 22:31:10 -0500 To: "Louis A. Mamakos" , Matthew Dillon From: Garance A Drosihn Subject: Re: Using a larger block size on large filesystems Cc: Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 6:11 PM -0500 12/7/01, Louis A. Mamakos wrote: >While we're gonna be changing the default file system characteristics, >how about having sysinstall create a reasonable size root file system >for today's disks? I think that if we're installing on a multi-gigabyte >disk, a 200MB root file system isn't imposing very much. I definitely think it should be larger, but 200 is a bit higher than I would push for. I'd feel a bit more comfortable with the default at 100 or 120 meg. I would not vote against 200 meg, but if it were me doing the pushing for the change, then I would be pick a number more like 100 meg. Any number between 100 meg and 250 meg would be fine with me, though. The current default is too low, and it's really painful when one runs out of disk space in the middle of a 'make installkernel'... -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 19:50:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 96C9137B416 for ; Fri, 7 Dec 2001 19:49:53 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB83nWU00292; Fri, 7 Dec 2001 19:49:32 -0800 (PST) (envelope-from dillon) Date: Fri, 7 Dec 2001 19:49:32 -0800 (PST) From: Matthew Dillon Message-Id: <200112080349.fB83nWU00292@apollo.backplane.com> To: Garance A Drosihn Cc: "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) References: <31807.1007732134@axl.seasidesoftware.co.za> <200112072257.fB7MvjE95211@apollo.backplane.com> <200112072311.fB7NB2723789@whizzo.transsys.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ok, I've finally gone and done it... cleaned up the sysinstall 'Auto' option. The jist of it is that I have added a bunch of DEFAULT and NOMINAL partition sizes. DEFAULT is the target 'A'uto tries to achieve, but if the disk is not large enough it will loop and scale the auto partitions down based on a fraction of NOMINAL to DEFAULT. I added "vn" to libdisk (not in this patch, just so I could test) and did some tests and it appears to work quite well. (Note: if using the VN device for testing you have to use file-backed rather then swap-backed because sysinstall gets really confused when the sector size is not 512). I also added two more 'typical' partitions: /var/tmp, and /home. I have not done anything with /tmp yet but I recommend that we have sysinstall create a softlink /tmp -> /var/tmp. I also fixed auto mode to not create more then 4G of swap. Auto now attempts to create the following partitions: / 128M swap 2 x phys memory, 32MB minimum /var 128M /var/tmp 128M /usr 3G max /home all remaining space Of course, these are all #defines so we can argue about them separately from comments on the patchset itself. NOTE!! This code will scale sizes down to fit the disk. For example if you only have a 4G disk then /usr will wind up being around 1.5G and /home around 1.5G. My reasoning for the partition sizes: / 128M - Big enough to store a couple of debug kernels and not have make install trip over a softupdates root (at least if you don't run 'make install' twice in a row). swap Default: 2 x main memory, 32MB min. Nominal: 50% main memory (if the disk isn't big enough). /var 128M - lets discuss this. I would actually like to make /var larger if the disk itself is huge, because the mail boxes and spool is on /var. /var/tmp 128M. /usr 3G default size, 512M nominal. I've found 3G to be a good size. /usr requires a considerable amount of space if you install linux emulation, X11, and various (large) ports like KDE, a browser, Apache, and so forth. We do not have enough partition id's to make a separate /usr/local. /home 3G default size, 512M nominal, *ALL* remaining space if the disk is large enough. -Matt Index: install.c =================================================================== RCS file: /home/ncvs/src/release/sysinstall/Attic/install.c,v retrieving revision 1.268.2.29 diff -u -r1.268.2.29 install.c --- install.c 2001/10/26 08:26:34 1.268.2.29 +++ install.c 2001/12/08 02:42:03 @@ -66,12 +66,12 @@ static void installConfigure(void); Boolean -checkLabels(Boolean whinge, Chunk **rdev, Chunk **sdev, Chunk **udev, Chunk **vdev) +checkLabels(Boolean whinge, Chunk **rdev, Chunk **sdev, Chunk **udev, Chunk **vdev, Chunk **vtdev, Chunk **hdev) { Device **devs; Boolean status; Disk *disk; - Chunk *c1, *c2, *rootdev, *swapdev, *usrdev, *vardev; + Chunk *c1, *c2, *rootdev, *swapdev, *usrdev, *vardev, *vartmpdev, *homedev; int i; /* Don't allow whinging if noWarn is set */ @@ -79,7 +79,19 @@ whinge = FALSE; status = TRUE; - *rdev = *sdev = *udev = *vdev = rootdev = swapdev = usrdev = vardev = NULL; + if (rdev) + *rdev = NULL; + if (sdev) + *sdev = NULL; + if (udev) + *udev = NULL; + if (vdev) + *vdev = NULL; + if (vtdev) + *vtdev = NULL; + if (hdev) + *hdev = NULL; + rootdev = swapdev = usrdev = vardev = vartmpdev = homedev = NULL; /* We don't need to worry about root/usr/swap if we're already multiuser */ if (!RunningAsInit) @@ -136,6 +148,30 @@ if (isDebug()) msgDebug("Found vardev at %s!\n", vardev->name); } + } else if (!strcmp(((PartInfo *)c2->private_data)->mountpoint, "/var/tmp")) { + if (vartmpdev) { + if (whinge) + msgConfirm("WARNING: You have more than one /var/tmp filesystem.\n" + "Using the first one found."); + continue; + } + else { + vartmpdev = c2; + if (isDebug()) + msgDebug("Found vartmpdev at %s!\n", vartmpdev->name); + } + } else if (!strcmp(((PartInfo *)c2->private_data)->mountpoint, "/home")) { + if (homedev) { + if (whinge) + msgConfirm("WARNING: You have more than one /home filesystem.\n" + "Using the first one found."); + continue; + } + else { + homedev = c2; + if (isDebug()) + msgDebug("Found homedev at %s!\n", homedev->name); + } } } } @@ -166,10 +202,18 @@ } /* Copy our values over */ - *rdev = rootdev; - *sdev = swapdev; - *udev = usrdev; - *vdev = vardev; + if (rdev) + *rdev = rootdev; + if (sdev) + *sdev = swapdev; + if (udev) + *udev = usrdev; + if (vdev) + *vdev = vardev; + if (vtdev) + *vtdev = vartmpdev; + if (hdev) + *hdev = homedev; if (!rootdev && whinge) { msgConfirm("No root device found - you must label a partition as /\n" @@ -868,7 +912,7 @@ { int i; Disk *disk; - Chunk *c1, *c2, *rootdev, *swapdev, *usrdev, *vardev; + Chunk *c1, *c2, *rootdev, *swapdev; Device **devs; PartInfo *root; char dname[80]; @@ -880,7 +924,7 @@ return DITEM_SUCCESS; upgrade = !variable_cmp(SYSTEM_STATE, "upgrade"); - if (!checkLabels(TRUE, &rootdev, &swapdev, &usrdev, &vardev)) + if (!checkLabels(TRUE, &rootdev, &swapdev, NULL, NULL, NULL, NULL)) return DITEM_FAILURE; if (rootdev) Index: label.c =================================================================== RCS file: /home/ncvs/src/release/sysinstall/Attic/label.c,v retrieving revision 1.98.2.5 diff -u -r1.98.2.5 label.c --- label.c 2001/05/09 08:00:30 1.98.2.5 +++ label.c 2001/12/08 03:43:38 @@ -54,29 +54,47 @@ /* The smallest filesystem we're willing to create */ #define FS_MIN_SIZE ONE_MEG -/* The smallest root filesystem we're willing to create */ +/* + * Minimum partition sizes + */ #ifdef __alpha__ #define ROOT_MIN_SIZE 40 #else #define ROOT_MIN_SIZE 30 #endif - -/* The default root filesystem size */ -#ifdef __alpha__ -#define ROOT_DEFAULT_SIZE 110 -#else -#define ROOT_DEFAULT_SIZE 100 -#endif - -/* The smallest swap partition we want to create by default */ #define SWAP_MIN_SIZE 32 - -/* The smallest /usr partition we're willing to create by default */ #define USR_MIN_SIZE 80 - -/* The smallest /var partition we're willing to create by default */ #define VAR_MIN_SIZE 20 +#define VARTMP_MIN_SIZE 20 +#define HOME_MIN_SIZE 20 +/* + * Swap size limit for auto-partitioning + */ +#define SWAP_AUTO_LIMIT_SIZE 4096 + +/* + * Default partition sizes. If we do not have sufficient disk space + * for this configuration we scale things relative to the NOM vs DEFAULT + * sizes. If the disk is larger then /home will get any remaining space. + */ +#define ROOT_DEFAULT_SIZE 128 +#define USR_DEFAULT_SIZE 3072 +#define VAR_DEFAULT_SIZE 128 +#define VARTMP_DEFAULT_SIZE 128 +#define HOME_DEFAULT_SIZE USR_DEFAULT_SIZE + +/* + * Nominal partition sizes. These are used to scale the default sizes down + * when we have insufficient disk space. If this isn't sufficient we scale + * down using the MIN sizes instead. + */ +#define ROOT_NOMINAL_SIZE 128 +#define USR_NOMINAL_SIZE 512 +#define VAR_NOMINAL_SIZE 64 +#define VARTMP_NOMINAL_SIZE 64 +#define HOME_NOMINAL_SIZE USR_NOMINAL_SIZE + /* The bottom-most row we're allowed to scribble on */ #define CHUNK_ROW_MAX 16 @@ -93,6 +111,7 @@ static int diskLabel(Device *dev); static int diskLabelNonInteractive(Device *dev); +static char *try_auto_label(Device **devs, Device *dev, int perc, int *req); static int labelHook(dialogMenuItem *selected) @@ -781,110 +800,23 @@ msg = "You can only do this in a disk slice (at top of screen)"; break; } - sz = space_free(label_chunk_info[here].c); - if (sz <= FS_MIN_SIZE) - msg = "Not enough free space to create a new partition in the slice"; - else { - struct chunk *tmp; - int mib[2]; - int physmem; - size_t size, swsize; - char *cp; - Chunk *rootdev, *swapdev, *usrdev, *vardev; - - (void)checkLabels(FALSE, &rootdev, &swapdev, &usrdev, &vardev); - if (!rootdev) { - cp = variable_get(VAR_ROOT_SIZE); - tmp = Create_Chunk_DWIM(label_chunk_info[here].c->disk, label_chunk_info[here].c, - (cp ? atoi(cp) : ROOT_DEFAULT_SIZE) * ONE_MEG, part, FS_BSDFFS, CHUNK_IS_ROOT); - if (!tmp) { - msgConfirm("Unable to create the root partition. Too big?"); - clear_wins(); - break; - } - tmp->private_data = new_part("/", TRUE, tmp->size); - tmp->private_free = safe_free; - record_label_chunks(devs, dev); - } - - if (!swapdev) { - cp = variable_get(VAR_SWAP_SIZE); - if (cp) - swsize = atoi(cp) * ONE_MEG; - else { - mib[0] = CTL_HW; - mib[1] = HW_PHYSMEM; - size = sizeof physmem; - sysctl(mib, 2, &physmem, &size, (void *)0, (size_t)0); - swsize = 16 * ONE_MEG + (physmem * 2 / 512); - } - tmp = Create_Chunk_DWIM(label_chunk_info[here].c->disk, label_chunk_info[here].c, - swsize, part, FS_SWAP, 0); - if (!tmp) { - msgConfirm("Unable to create the swap partition. Too big?"); - clear_wins(); + { + int perc; + int req; + + req = 0; + for (perc = 100; perc > 0; perc -= 10) { + req = 0; /* reset for each loop */ + if ((msg = try_auto_label(devs, dev, perc, &req)) == NULL) break; - } - tmp->private_data = 0; - tmp->private_free = safe_free; - record_label_chunks(devs, dev); } - - if (!vardev) { - cp = variable_get(VAR_VAR_SIZE); - if (cp) - sz = atoi(cp) * ONE_MEG; - else - sz = variable_get(VAR_NO_USR) - ? space_free(label_chunk_info[here].c) - : VAR_MIN_SIZE * ONE_MEG; - - tmp = Create_Chunk_DWIM(label_chunk_info[here].c->disk, label_chunk_info[here].c, - sz, part, FS_BSDFFS, 0); - if (!tmp) { - msgConfirm("Less than %dMB free for /var - you will need to\n" - "partition your disk manually with a custom install!", - (cp ? atoi(cp) : VAR_MIN_SIZE)); + if (msg) { + if (req) { + msgConfirm(msg); clear_wins(); - break; - } - tmp->private_data = new_part("/var", TRUE, tmp->size); - tmp->private_free = safe_free; - record_label_chunks(devs, dev); - } - - if (!usrdev && !variable_get(VAR_NO_USR)) { - cp = variable_get(VAR_USR_SIZE); - if (cp) - sz = atoi(cp) * ONE_MEG; - else - sz = space_free(label_chunk_info[here].c); - if (sz) { - if (sz < (USR_MIN_SIZE * ONE_MEG)) { - msgConfirm("Less than %dMB free for /usr - you will need to\n" - "partition your disk manually with a custom install!", USR_MIN_SIZE); - clear_wins(); - break; - } - - tmp = Create_Chunk_DWIM(label_chunk_info[here].c->disk, - label_chunk_info[here].c, - sz, part, FS_BSDFFS, 0); - if (!tmp) { - msgConfirm("Unable to create the /usr partition. Not enough space?\n" - "You will need to partition your disk manually with a custom install!"); - clear_wins(); - break; - } - tmp->private_data = new_part("/usr", TRUE, tmp->size); - tmp->private_free = safe_free; - record_label_chunks(devs, dev); + msg = NULL; } } - - /* At this point, we're reasonably "labelled" */ - if (variable_cmp(DISK_LABELLED, "written")) - variable_set2(DISK_LABELLED, "yes", 0); } break; @@ -1172,6 +1104,189 @@ } restorescr(w); return DITEM_SUCCESS; +} + +static __inline int +requested_part_size(char *varName, int nom, int def, int perc) +{ + char *cp; + int sz; + + if ((cp = variable_get(VAR_ROOT_SIZE)) != NULL) + sz = atoi(cp); + else + sz = nom + (def - nom) * perc / 100; + return(sz * ONE_MEG); +} + +static char * +try_auto_label(Device **devs, Device *dev, int perc, int *req) +{ + int sz; + struct chunk *root_chunk = NULL; + struct chunk *swap_chunk = NULL; + struct chunk *usr_chunk = NULL; + struct chunk *var_chunk = NULL; + struct chunk *vartmp_chunk = NULL; + struct chunk *home_chunk = NULL; + int mib[2]; + unsigned int physmem; + size_t size; + Chunk *rootdev, *swapdev, *usrdev, *vardev; + Chunk *vartmpdev, *homedev; + char *msg = NULL; + + sz = space_free(label_chunk_info[here].c); + if (sz <= FS_MIN_SIZE) + return("Not enough free space to create a new partition in the slice"); + + (void)checkLabels(FALSE, &rootdev, &swapdev, &usrdev, + &vardev, &vartmpdev, &homedev); + if (!rootdev) { + sz = requested_part_size(VAR_ROOT_SIZE, ROOT_NOMINAL_SIZE, ROOT_DEFAULT_SIZE, perc); + + root_chunk = Create_Chunk_DWIM(label_chunk_info[here].c->disk, label_chunk_info[here].c, + sz, part, FS_BSDFFS, CHUNK_IS_ROOT); + if (!root_chunk) { + *req = 1; + msg = "Unable to create the root partition. Too big?"; + goto done; + } + root_chunk->private_data = new_part("/", TRUE, root_chunk->size); + root_chunk->private_free = safe_free; + record_label_chunks(devs, dev); + } + if (!swapdev) { + sz = requested_part_size(VAR_SWAP_SIZE, 0, 0, perc); + if (sz == 0) { + int nom; + int def; + + mib[0] = CTL_HW; + mib[1] = HW_PHYSMEM; + size = sizeof physmem; + sysctl(mib, 2, &physmem, &size, (void *)0, (size_t)0); + def = 2 * (int)(physmem / 512); + if (def < SWAP_MIN_SIZE * ONE_MEG) + def = SWAP_MIN_SIZE * ONE_MEG; + if (def > SWAP_AUTO_LIMIT_SIZE * ONE_MEG) + def = SWAP_AUTO_LIMIT_SIZE * ONE_MEG; + nom = (int)(physmem / 512) / 2; + sz = nom + (def - nom) * perc / 100; + } + swap_chunk = Create_Chunk_DWIM(label_chunk_info[here].c->disk, label_chunk_info[here].c, + sz, part, FS_SWAP, 0); + if (!swap_chunk) { + *req = 1; + msg = "Unable to create the swap partition. Too big?"; + goto done; + } + swap_chunk->private_data = 0; + swap_chunk->private_free = safe_free; + record_label_chunks(devs, dev); + } + if (!vardev) { + sz = requested_part_size(VAR_VAR_SIZE, VAR_NOMINAL_SIZE, VAR_DEFAULT_SIZE, perc); + + var_chunk = Create_Chunk_DWIM(label_chunk_info[here].c->disk, label_chunk_info[here].c, + sz, part, FS_BSDFFS, 0); + if (!var_chunk) { + *req = 1; + msg = "Not enough free space for /var - you will need to\n" + "partition your disk manually with a custom install!"; + goto done; + } + var_chunk->private_data = new_part("/var", TRUE, var_chunk->size); + var_chunk->private_free = safe_free; + record_label_chunks(devs, dev); + } + if (!vartmpdev && !variable_get(VAR_NO_VARTMP)) { + sz = requested_part_size(VAR_VARTMP_SIZE, VARTMP_NOMINAL_SIZE, VARTMP_DEFAULT_SIZE, perc); + + vartmp_chunk = Create_Chunk_DWIM(label_chunk_info[here].c->disk, label_chunk_info[here].c, + sz, part, FS_BSDFFS, 0); + if (!vartmp_chunk) { + *req = 1; + msg = "Not enough free space for /var/tmp - you will need to\n" + "partition your disk manually with a custom install!"; + goto done; + } + vartmp_chunk->private_data = new_part("/var/tmp", TRUE, vartmp_chunk->size); + vartmp_chunk->private_free = safe_free; + record_label_chunks(devs, dev); + } + if (!usrdev && !variable_get(VAR_NO_USR)) { + sz = requested_part_size(VAR_USR_SIZE, USR_NOMINAL_SIZE, USR_DEFAULT_SIZE, perc); +#if 0 + sz = space_free(label_chunk_info[here].c); +#endif + if (sz) { + if (sz < (USR_MIN_SIZE * ONE_MEG)) { + *req = 1; + msg = "Not enough free space for /usr - you will need to\n" + "partition your disk manually with a custom install!"; + } + + usr_chunk = Create_Chunk_DWIM(label_chunk_info[here].c->disk, + label_chunk_info[here].c, + sz, part, FS_BSDFFS, 0); + if (!usr_chunk) { + msg = "Unable to create the /usr partition. Not enough space?\n" + "You will need to partition your disk manually with a custom install!"; + goto done; + } + usr_chunk->private_data = new_part("/usr", TRUE, usr_chunk->size); + usr_chunk->private_free = safe_free; + record_label_chunks(devs, dev); + } + } + if (!homedev && !variable_get(VAR_NO_HOME)) { + sz = requested_part_size(VAR_HOME_SIZE, HOME_NOMINAL_SIZE, HOME_DEFAULT_SIZE, perc); + if (sz < space_free(label_chunk_info[here].c)) + sz = space_free(label_chunk_info[here].c); + if (sz) { + if (sz < (HOME_MIN_SIZE * ONE_MEG)) { + *req = 1; + msg = "Not enough free space for /home - you will need to\n" + "partition your disk manually with a custom install!"; + goto done; + } + + home_chunk = Create_Chunk_DWIM(label_chunk_info[here].c->disk, + label_chunk_info[here].c, + sz, part, FS_BSDFFS, 0); + if (!home_chunk) { + msg = "Unable to create the /home partition. Not enough space?\n" + "You will need to partition your disk manually with a custom install!"; + goto done; + } + home_chunk->private_data = new_part("/home", TRUE, home_chunk->size); + home_chunk->private_free = safe_free; + record_label_chunks(devs, dev); + } + } + + /* At this point, we're reasonably "labelled" */ + if (variable_cmp(DISK_LABELLED, "written")) + variable_set2(DISK_LABELLED, "yes", 0); + +done: + if (msg) { + if (root_chunk) + Delete_Chunk(root_chunk->disk, root_chunk); + if (swap_chunk) + Delete_Chunk(swap_chunk->disk, swap_chunk); + if (var_chunk) + Delete_Chunk(var_chunk->disk, var_chunk); + if (vartmp_chunk) + Delete_Chunk(vartmp_chunk->disk, vartmp_chunk); + if (usr_chunk) + Delete_Chunk(usr_chunk->disk, usr_chunk); + if (home_chunk) + Delete_Chunk(home_chunk->disk, home_chunk); + record_label_chunks(devs, dev); + } + return(msg); } static int Index: sysinstall.h =================================================================== RCS file: /home/ncvs/src/release/sysinstall/Attic/sysinstall.h,v retrieving revision 1.186.2.25 diff -u -r1.186.2.25 sysinstall.h --- sysinstall.h 2001/10/26 09:25:01 1.186.2.25 +++ sysinstall.h 2001/12/08 02:22:31 @@ -150,6 +150,8 @@ #define VAR_NO_HOLOSHELL "noHoloShell" #define VAR_NO_WARN "noWarn" #define VAR_NO_USR "noUsr" +#define VAR_NO_VARTMP "noVarTmp" +#define VAR_NO_HOME "noHome" #define VAR_NONINTERACTIVE "nonInteractive" #define VAR_NOVELL "novell" #define VAR_NTPDATE_FLAGS "ntpdate_flags" @@ -174,6 +176,8 @@ #define VAR_UFS_PATH "ufs" #define VAR_USR_SIZE "usrSize" #define VAR_VAR_SIZE "varSize" +#define VAR_VARTMP_SIZE "varTmpSize" +#define VAR_HOME_SIZE "homeSize" #define VAR_XF86_CONFIG "_xf86config" #define VAR_TERM "TERM" @@ -572,7 +576,7 @@ PkgNodePtr index_search(PkgNodePtr top, char *str, PkgNodePtr *tp); /* install.c */ -extern Boolean checkLabels(Boolean whinge, Chunk **rdev, Chunk **sdev, Chunk **udev, Chunk **vdev); +extern Boolean checkLabels(Boolean whinge, Chunk **rdev, Chunk **sdev, Chunk **udev, Chunk **vdev, Chunk **vtdev, Chunk **hdev); extern int installCommit(dialogMenuItem *self); extern int installCustomCommit(dialogMenuItem *self); extern int installExpress(dialogMenuItem *self); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 20: 0: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id A453337B405; Fri, 7 Dec 2001 20:00:03 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB8403P00383; Fri, 7 Dec 2001 20:00:03 -0800 (PST) (envelope-from dillon) Date: Fri, 7 Dec 2001 20:00:03 -0800 (PST) From: Matthew Dillon Message-Id: <200112080400.fB8403P00383@apollo.backplane.com> To: Robert Watson Cc: "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :While we can discuss the merits of doing this for the -STABLE branch, I :for one will be quite happy to see this be the case for -CURRENT, where :storing three complete sets of kernels and modules (kernel.new, :kernel.old, and kernel.dontworryaboutmeiamsafe) consumes vast amounts of :disk space with the various debugging symbols, et al. The sysinstall code is virtually identical between -stable and -current. I'm developing these patches under -stable but will obviously test & commit under -current before MFCing to stable. :BTW, we keep suggesting people would be foolish to use anything other than :MFS/md for /tmp (and maybe other variations on tmp), but our sysinstall :doesn't support doing this "automagically". I'm not sure what the right :vehicle is for that in sysinstall, but it would be nice to see. Another :interesting problem with the current partition layout is the extremely :small size of /var, on which we find /var/tmp, which is used for package My patch adds a /var/tmp. 128M for the moment. We can discuss it. The main thing is that my patch adds a framework by which we can more easily fit the partitions onto an (almost) arbitrarily small or large disk. I also added a /home, because it's just not a good idea to put people's home directories in the same filesystem as /usr where a user might fill up the partition. I strongly disagree with MDing /tmp. It's a hugely bad idea. The absolute safest thing to do is to make /tmp a softlink or a null-mount to /var/tmp (though I'm still not sure how good an idea it is to have a null-mount in the default system considering their history of instability). -Matt :unpacking before installation. For large packages, such as KDE, LaTeX, :and friends, this can be a big problem, as well as for vmware which likes :to drop huge paging files into /var/tmp. Combining these various :temporary spaces into a single md partition sized to something appropriate :might make sense. This is seperate issue from the root partition, of :course, but something we might want to look into a strateg for. : :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-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 21:11:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 2B75437B417 for ; Fri, 7 Dec 2001 21:11:41 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id AAA01845; Sat, 8 Dec 2001 00:11:35 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id fB85BA104147; Sat, 8 Dec 2001 00:11:10 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15377.41198.83638.460387@grasshopper.cs.duke.edu> Date: Sat, 8 Dec 2001 00:11:10 -0500 (EST) To: Matthew Dillon Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: <200112080349.fB83nWU00292@apollo.backplane.com> References: <31807.1007732134@axl.seasidesoftware.co.za> <200112072257.fB7MvjE95211@apollo.backplane.com> <200112072311.fB7NB2723789@whizzo.transsys.com> <200112080349.fB83nWU00292@apollo.backplane.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon writes: <..> Nice. I like it except for the size of /var: > /var 128M - lets discuss this. I would actually like to make > /var larger if the disk itself is huge, because the mail > boxes and spool is on /var. Let's not forget /var/crash. I always make var at least twice as large as the physical memory in the box, plus some slop, so I have enough room to hold 2 crashdumps. Cheers, Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 7 21:44: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 6228E37B405 for ; Fri, 7 Dec 2001 21:43:59 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB85hSt00738; Fri, 7 Dec 2001 21:43:28 -0800 (PST) (envelope-from dillon) Date: Fri, 7 Dec 2001 21:43:28 -0800 (PST) From: Matthew Dillon Message-Id: <200112080543.fB85hSt00738@apollo.backplane.com> To: Andrew Gallatin Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) References: <31807.1007732134@axl.seasidesoftware.co.za> <200112072257.fB7MvjE95211@apollo.backplane.com> <200112072311.fB7NB2723789@whizzo.transsys.com> <200112080349.fB83nWU00292@apollo.backplane.com> <15377.41198.83638.460387@grasshopper.cs.duke.edu> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :Nice. I like it except for the size of /var: : : > /var 128M - lets discuss this. I would actually like to make : > /var larger if the disk itself is huge, because the mail : > boxes and spool is on /var. : :Let's not forget /var/crash. I always make var at least twice as :large as the physical memory in the box, plus some slop, so I have :enough room to hold 2 crashdumps. : :Cheers, : :Drew That's problematic. /var's size requirements tend to be fairly static, unrelated to the amount of memory the machine might have. A machine that doesn't act as a mail spool or repository generally doesn't need a large /var. So if you have a machine with 512M of ram and we create a 1G /var it will almost certainly remain 99% empty for the entire life of the machine. The only time I have ever created a /var larger then 512M is on mail relays and shell machines with thousands of users. So creating a /var based on available physical ram is problematic. If your machine has a lot of memory you will almost certainly be wasting a huge amount of disk space for a /var that will never get more then 1% full (except for the occassional crash dump) It isn't worth it. What I do, personally, is cap /var at 512M and if I have a machine with more memory and I want crash dumps I softlink /var/crash to either /usr/var.crash, or /home/var.crash. Or I run savecore manually to another directory after boot. My recommendation for auto-generating /var is that we not make it larger then 512M. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 0:10:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 5F28137B417 for ; Sat, 8 Dec 2001 00:10:34 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB88AYA01750; Sat, 8 Dec 2001 00:10:34 -0800 (PST) (envelope-from dillon) Date: Sat, 8 Dec 2001 00:10:34 -0800 (PST) From: Matthew Dillon Message-Id: <200112080810.fB88AYA01750@apollo.backplane.com> To: Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Revised auto-sizing patch to sysinstall (for -current and -stable) w/ instructions for testing. References: <31807.1007732134@axl.seasidesoftware.co.za> <200112072257.fB7MvjE95211@apollo.backplane.com> <200112072311.fB7NB2723789@whizzo.transsys.com> <200112080349.fB83nWU00292@apollo.backplane.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The revised auto-sizing patch for sysinstall is now available for both -stable and -current. I changed the /var and /var/tmp target sizes to 256MB each, and generated a separate patch against -current. The new target sizes seem to work better for smaller disks (it doesn't knock them down too as much as it would otherwise), and are obviously fine for larger disks. The -current patchset is a commit candidate, the -stable patchset is an MFC candidate. http://apollo.backplane.com/FreeBSD/ http://apollo.backplane.com/FreeBSD/sysinstall-401.diff (STABLE) http://apollo.backplane.com/FreeBSD/sysinstall-501.diff (CURRENT) ---- TESTING Testing with VN or MD requires a couple of hacks that are not part of the official patch set. In lib/libdisk/disk.c add "vn" to the device_list for -stable, "md" for -current. recompile and install. Remove the hacks in the source before continuing so you don't accidently commit it later. For -current, in usr.sbin/sysinstall/devices.c deviceGetAll() around line 442 there is an explicit check to weed out "md". Remove the check (#if 0 it out). Create a vnode-backed VN or MD device as appropriate (for MD devices you have to use /usr/bin/truncate to pre-create the file). As long as you don't actually do anything major with it you can create an arbitrarily sized vnode backing file on a small filesystem. sysinstall should then recognize an appropriately configured VN or MD device. Again, for testing only. Remember to remove the hacks when done so you don't accidently commit the hacks later. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 6:56: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Veronica.wmol.com (veronica.wmol.com [208.242.83.241]) by hub.freebsd.org (Postfix) with ESMTP id 892EB37B417 for ; Sat, 8 Dec 2001 06:56:03 -0800 (PST) Received: from rain.hill.hom (24.247.83.42.bay.mi.chartermi.net [24.247.83.42]) by Veronica.wmol.com (Vircom SMTPRS 5.0.193) with ESMTP id for ; Sat, 8 Dec 2001 09:52:19 -0500 Date: Sat, 8 Dec 2001 09:54:50 +0000 From: David Hill To: freebsd-arch@freebsd.org Subject: write.c diff Message-Id: <20011208095450.76a07a6f.lists@phobia.ms> X-Mailer: Sylpheed version 0.6.5 (GTK+ 1.2.10; i386--freebsd5.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart_Sat__8_Dec_2001_09:54:50_+0000_0817f600" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --Multipart_Sat__8_Dec_2001_09:54:50_+0000_0817f600 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello - Here is a small code cleanup patch for write(1). - David --- /usr/src/usr.bin/write/write.c.orig Mon Dec 3 17:42:45 2001 +++ /usr/src/usr.bin/write/write.c Mon Dec 3 17:45:22 2001 @@ -190,8 +190,7 @@ while (read(ufd, (char *) &u, sizeof(u)) == sizeof(u)) if (strncmp(user, u.ut_name, sizeof(u.ut_name)) == 0) { ++nloggedttys; - (void)strncpy(atty, u.ut_line, UT_LINESIZE); - atty[UT_LINESIZE] = '\0'; + (void)strlcpy(atty, u.ut_line, UT_LINESIZE); if (term_chk(atty, &msgsok, &atime, 0)) continue; /* bad term? skip */ if (myuid && !msgsok) @@ -240,7 +239,7 @@ warn("%s", path); return(1); } - *msgsokP = (s.st_mode & (S_IWRITE >> 3)) != 0; /* group write bit */ + *msgsokP = (s.st_mode & S_IWGRP) != 0; /* group write bit */ *atimeP = s.st_atime; return(0); } --Multipart_Sat__8_Dec_2001_09:54:50_+0000_0817f600 Content-Type: application/octet-stream; name="write.c.diff" Content-Disposition: attachment; filename="write.c.diff" Content-Transfer-Encoding: base64 LS0tIC91c3Ivc3JjL3Vzci5iaW4vd3JpdGUvd3JpdGUuYy5vcmlnCU1vbiBEZWMgIDMgMTc6NDI6 NDUgMjAwMQorKysgL3Vzci9zcmMvdXNyLmJpbi93cml0ZS93cml0ZS5jCU1vbiBEZWMgIDMgMTc6 NDU6MjIgMjAwMQpAQCAtMTkwLDggKzE5MCw3IEBACiAJd2hpbGUgKHJlYWQodWZkLCAoY2hhciAq KSAmdSwgc2l6ZW9mKHUpKSA9PSBzaXplb2YodSkpCiAJCWlmIChzdHJuY21wKHVzZXIsIHUudXRf bmFtZSwgc2l6ZW9mKHUudXRfbmFtZSkpID09IDApIHsKIAkJCSsrbmxvZ2dlZHR0eXM7Ci0JCQko dm9pZClzdHJuY3B5KGF0dHksIHUudXRfbGluZSwgVVRfTElORVNJWkUpOwotCQkJYXR0eVtVVF9M SU5FU0laRV0gPSAnXDAnOworCQkJKHZvaWQpc3RybGNweShhdHR5LCB1LnV0X2xpbmUsIFVUX0xJ TkVTSVpFKTsKIAkJCWlmICh0ZXJtX2NoayhhdHR5LCAmbXNnc29rLCAmYXRpbWUsIDApKQogCQkJ CWNvbnRpbnVlOwkvKiBiYWQgdGVybT8gc2tpcCAqLwogCQkJaWYgKG15dWlkICYmICFtc2dzb2sp CkBAIC0yNDAsNyArMjM5LDcgQEAKIAkJCXdhcm4oIiVzIiwgcGF0aCk7CiAJCXJldHVybigxKTsK IAl9Ci0JKm1zZ3Nva1AgPSAocy5zdF9tb2RlICYgKFNfSVdSSVRFID4+IDMpKSAhPSAwOwkvKiBn cm91cCB3cml0ZSBiaXQgKi8KKwkqbXNnc29rUCA9IChzLnN0X21vZGUgJiBTX0lXR1JQKSAhPSAw OwkvKiBncm91cCB3cml0ZSBiaXQgKi8KIAkqYXRpbWVQID0gcy5zdF9hdGltZTsKIAlyZXR1cm4o MCk7CiB9Cg== --Multipart_Sat__8_Dec_2001_09:54:50_+0000_0817f600-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 7:13:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id B2D4937B417 for ; Sat, 8 Dec 2001 07:13:15 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fB8FCuF43597; Sat, 8 Dec 2001 17:12:56 +0200 (EET) (envelope-from ru) Date: Sat, 8 Dec 2001 17:12:56 +0200 From: Ruslan Ermilov To: David Hill Cc: freebsd-arch@FreeBSD.ORG Subject: Re: write.c diff Message-ID: <20011208171256.H32556@sunbay.com> References: <20011208095450.76a07a6f.lists@phobia.ms> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011208095450.76a07a6f.lists@phobia.ms> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Dec 08, 2001 at 09:54:50AM +0000, David Hill wrote: > Hello - > Here is a small code cleanup patch for write(1). > > --- /usr/src/usr.bin/write/write.c.orig Mon Dec 3 17:42:45 2001 > +++ /usr/src/usr.bin/write/write.c Mon Dec 3 17:45:22 2001 [...] This ML is not an appropriate place for code reviews. Please resend it to audit@FreeBSD.org. Thanks, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 10:13: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id A6AE937B405 for ; Sat, 8 Dec 2001 10:12:54 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.0/8.11.0) with UUCP id fB8ICb663397; Sat, 8 Dec 2001 19:12:37 +0100 (CET) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id fB8I8Gtx055717; Sat, 8 Dec 2001 19:08:17 +0100 (CET)?g (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id fB8I8GW01934; Sat, 8 Dec 2001 19:08:16 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.6/8.11.6) id fB8I8F006143; Sat, 8 Dec 2001 19:08:15 +0100 (CET) (envelope-from ticso) Date: Sat, 8 Dec 2001 19:08:14 +0100 From: Bernd Walter To: Marko Zec Cc: "Louis A. Mamakos" , freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems Message-ID: <20011208190814.A5998@cicely8.cicely.de> References: <31807.1007732134@axl.seasidesoftware.co.za> <200112072257.fB7MvjE95211@apollo.backplane.com> <200112072311.fB7NB2723789@whizzo.transsys.com> <3C114FDF.138E09A7@tel.fer.hr> <200112072331.fB7NVM724075@whizzo.transsys.com> <3C1156B1.F44F844B@tel.fer.hr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C1156B1.F44F844B@tel.fer.hr> User-Agent: Mutt/1.3.23i X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Dec 08, 2001 at 12:54:25AM +0100, Marko Zec wrote: > My point is if we all get used to seeing huge amounts of free space in /, then > we'll all be tempted to fill it up sooner or later with necessary or unnecessary > stuff. And then we can go into another cycle of / size expansion, and so on. Right > now my 4.4-R / uses 30M of space with a spare kernel image included, and I am not > feeling comfortable seeing it enlarged by an order of magnitude in the next > release. Those guys doing heavy development and needing multiple kernel/module > trees will anyhow make a custom partitioning, and for all other people a compact > sized / should be enough. Of course with /tmp extracted :) This is a / fs on a -current: ticso@cicely5# df -k / Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0s1a 38991 31022 4850 86% / And it's not /boot that filling it as I massivly reduced the contents: ticso@cicely5# du -k /boot 2684 /boot/kernel 12 /boot/defaults 1 /boot/modules 2241 /boot/kernel.work 5338 /boot A typical filled kernel directory is about 10-12M. Space is needed in /bin and /sbin: ticso@cicely5# du -k /bin /sbin 6224 /bin 16484 /sbin And /sbin is also reduced in my system. It's 40M sized because back in 2.2.x days it was absolutely more than enough. In todays situation I see 200M to be a good future size. Maybe we should tunefs to leave only a small amount space free to use. That way people get a clear sign not to fill it up. I'am still dreaming of a /boot partition and a volumegroup handling for everything else using vinum via sysinstall. Adding volumegroups to vinum isn't a difficult task as it's only a new labeltype. What needs to be done is that sysinstall knows the filling space for each directory and can help the user in his decision. Those who ever run the HP-UX installer will know what I mean. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 10:27:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 1065037B41B for ; Sat, 8 Dec 2001 10:27:28 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id fB8IQwP11534; Sat, 8 Dec 2001 10:26:58 -0800 (PST) (envelope-from obrien) Date: Sat, 8 Dec 2001 10:26:58 -0800 From: "David O'Brien" To: Marko Zec Cc: "Louis A. Mamakos" , Matthew Dillon , Sheldon Hearn , freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems Message-ID: <20011208102658.B11428@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <31807.1007732134@axl.seasidesoftware.co.za> <200112072257.fB7MvjE95211@apollo.backplane.com> <200112072311.fB7NB2723789@whizzo.transsys.com> <3C114FDF.138E09A7@tel.fer.hr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C114FDF.138E09A7@tel.fer.hr>; from zec@tel.fer.hr on Sat, Dec 08, 2001 at 12:25:19AM +0100 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Dec 08, 2001 at 12:25:19AM +0100, Marko Zec wrote: > > for today's disks? I think that if we're installing on a multi-gigabyte > > disk, a 200MB root file system isn't imposing very much. > > Why would we want to do that? Putting unnecessary things on / is always a > bad idea, as root partition should remain small and as free of frequent RW > operations as possible. That is a *PERSONAL* opinion, so please mark it as such. I personally use 1.5GB / partitions. I _personally_ see zero reason for a /usr partition. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 10:31: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id E444A37B41E for ; Sat, 8 Dec 2001 10:31:00 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id fB8IUm511611; Sat, 8 Dec 2001 10:30:48 -0800 (PST) (envelope-from obrien) Date: Sat, 8 Dec 2001 10:30:48 -0800 From: "David O'Brien" To: Matthew Dillon Cc: Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) Message-ID: <20011208103048.C11428@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <31807.1007732134@axl.seasidesoftware.co.za> <200112072257.fB7MvjE95211@apollo.backplane.com> <200112072311.fB7NB2723789@whizzo.transsys.com> <200112080349.fB83nWU00292@apollo.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: <200112080349.fB83nWU00292@apollo.backplane.com>; from dillon@apollo.backplane.com on Fri, Dec 07, 2001 at 07:49:32PM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Dec 07, 2001 at 07:49:32PM -0800, Matthew Dillon wrote: > We do not have enough partition id's to make a separate > /usr/local. Has anyone considered raising the max number of partitions from 8 to 16 as OpenBSD did years ago? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 10:34: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 3C8ED37B417; Sat, 8 Dec 2001 10:34:06 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id fB8IY5011679; Sat, 8 Dec 2001 10:34:05 -0800 (PST) (envelope-from obrien) Date: Sat, 8 Dec 2001 10:34:05 -0800 From: "David O'Brien" To: Matthew Dillon Cc: Robert Watson , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems Message-ID: <20011208103405.D11428@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <200112080400.fB8403P00383@apollo.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: <200112080400.fB8403P00383@apollo.backplane.com>; from dillon@apollo.backplane.com on Fri, Dec 07, 2001 at 08:00:03PM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Dec 07, 2001 at 08:00:03PM -0800, Matthew Dillon wrote: > > I strongly disagree with MDing /tmp. It's a hugely bad idea. I know you've mentioned this before. Are there technical reasons behind this? I believe you mentioned something about the buffer cache? Would you be willing to add it as an option since so many others seem to want it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 11: 7: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 8FE4137B417 for ; Sat, 8 Dec 2001 11:07:00 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB8J6xi06097; Sat, 8 Dec 2001 11:06:59 -0800 (PST) (envelope-from dillon) Date: Sat, 8 Dec 2001 11:06:59 -0800 (PST) From: Matthew Dillon Message-Id: <200112081906.fB8J6xi06097@apollo.backplane.com> To: "David O'Brien" Cc: Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) References: <31807.1007732134@axl.seasidesoftware.co.za> <200112072257.fB7MvjE95211@apollo.backplane.com> <200112072311.fB7NB2723789@whizzo.transsys.com> <200112080349.fB83nWU00292@apollo.backplane.com> <20011208103048.C11428@dragon.nuxi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :On Fri, Dec 07, 2001 at 07:49:32PM -0800, Matthew Dillon wrote: :> We do not have enough partition id's to make a separate :> /usr/local. : :Has anyone considered raising the max number of partitions from 8 to 16 :as OpenBSD did years ago? Yes. We can't (in stable) without major device number surgery. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 11: 9:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id A8AEB37B405; Sat, 8 Dec 2001 11:09:29 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB8J9TB06131; Sat, 8 Dec 2001 11:09:29 -0800 (PST) (envelope-from dillon) Date: Sat, 8 Dec 2001 11:09:29 -0800 (PST) From: Matthew Dillon Message-Id: <200112081909.fB8J9TB06131@apollo.backplane.com> To: "David O'Brien" Cc: Robert Watson , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems References: <200112080400.fB8403P00383@apollo.backplane.com> <20011208103405.D11428@dragon.nuxi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :I know you've mentioned this before. Are there technical reasons behind :this? I believe you mentioned something about the buffer cache? Would :you be willing to add it as an option since so many others seem to want :it? Most of the stuff that winds up in /tmp is garbage. There is no good reason to burden our VM system with unnecessary garbage and I know of no performance issues involved with people using /tmp files that requires MFS or MD. It's an unnecessary waste of memory and an unnecessary burden on our VM system. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 11:11:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 9C3AA37B421 for ; Sat, 8 Dec 2001 11:11:29 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB8JBTW06147; Sat, 8 Dec 2001 11:11:29 -0800 (PST) (envelope-from dillon) Date: Sat, 8 Dec 2001 11:11:29 -0800 (PST) From: Matthew Dillon Message-Id: <200112081911.fB8JBTW06147@apollo.backplane.com> To: "David O'Brien" Cc: Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) References: <31807.1007732134@axl.seasidesoftware.co.za> <200112072257.fB7MvjE95211@apollo.backplane.com> <200112072311.fB7NB2723789@whizzo.transsys.com> <200112080349.fB83nWU00292@apollo.backplane.com> <20011208103048.C11428@dragon.nuxi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :On Fri, Dec 07, 2001 at 07:49:32PM -0800, Matthew Dillon wrote: :> We do not have enough partition id's to make a separate :> /usr/local. : :Has anyone considered raising the max number of partitions from 8 to 16 :as OpenBSD did years ago? Oh, by the way... there is actually a way you can bump up the number of partitions. What you do is split the disk up into multiple slices. We have 4, after all. You can then disklabel each one. This is apollo.backplane.com: apollo:/usr/src/release/sysinstall# df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0s1a 127023 56412 60450 48% / /dev/da0s1d 12862777 4386316 7447439 37% /FreeBSD /dev/da0s1e 508143 212588 254904 45% /var /dev/da0s1f 508143 120685 346807 26% /var/tmp /dev/da0s1g 4065262 751379 2988663 20% /usr /dev/da0s1h 4065262 1702069 2037973 46% /home /dev/da0s2a 127023 44209 72653 38% /altroot /dev/da0s2d 2032623 782315 1087699 42% /archive /dev/da0s2e 3048942 1853940 951087 66% /u1 /dev/da0s2f 4065262 1218095 2521947 33% /images /dev/da0s2g 4065262 301348 3438694 8% /cvs /dev/da0s2h 9813819 1079646 7949068 12% /usr/obj /dev/da0s3d 23871066 19009252 2952130 87% /backup1 procfs 4 4 0 100% /proc 10.0.0.2:/samba/htdocs 32817052 7715764 22475924 26% /home/mike/share/backplane -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 11:52: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by hub.freebsd.org (Postfix) with ESMTP id 58BCF37B41B for ; Sat, 8 Dec 2001 11:51:52 -0800 (PST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.6/8.11.6) id fB8JpVs56662; Sat, 8 Dec 2001 20:51:31 +0100 (CET) (envelope-from wkb) Date: Sat, 8 Dec 2001 20:51:31 +0100 From: Wilko Bulte To: Matthew Dillon Cc: "David O'Brien" , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) Message-ID: <20011208205131.A56648@freebie.xs4all.nl> References: <31807.1007732134@axl.seasidesoftware.co.za> <200112072257.fB7MvjE95211@apollo.backplane.com> <200112072311.fB7NB2723789@whizzo.transsys.com> <200112080349.fB83nWU00292@apollo.backplane.com> <20011208103048.C11428@dragon.nuxi.com> <200112081911.fB8JBTW06147@apollo.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: <200112081911.fB8JBTW06147@apollo.backplane.com>; from dillon@apollo.backplane.com on Sat, Dec 08, 2001 at 11:11:29AM -0800 X-OS: FreeBSD 4.4-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Dec 08, 2001 at 11:11:29AM -0800, Matthew Dillon wrote: > > : > :On Fri, Dec 07, 2001 at 07:49:32PM -0800, Matthew Dillon wrote: > :> We do not have enough partition id's to make a separate > :> /usr/local. > : > :Has anyone considered raising the max number of partitions from 8 to 16 > :as OpenBSD did years ago? > > Oh, by the way... there is actually a way you can bump up the number > of partitions. What you do is split the disk up into multiple slices. > We have 4, after all. You can then disklabel each one. This works on x86 but not on alpha which does not use slices. -- | / o / /_ _ email: wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 12:44:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 5C72537B417; Sat, 8 Dec 2001 12:44:47 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fB8Ko1T01347; Sat, 8 Dec 2001 12:50:01 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112082050.fB8Ko1T01347@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: arch@FreeBSD.ORG Cc: Marko Zec , "Louis A. Mamakos" , Matthew Dillon , Sheldon Hearn , freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems In-reply-to: Your message of "Sat, 08 Dec 2001 10:26:58 PST." <20011208102658.B11428@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 Dec 2001 12:50:01 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > Why would we want to do that? Putting unnecessary things on / is always a > > bad idea, as root partition should remain small and as free of frequent RW > > operations as possible. > > That is a *PERSONAL* opinion, so please mark it as such. I personally > use 1.5GB / partitions. I _personally_ see zero reason for a /usr > partition. PERSONALLY, I disagree. 1.5GB is too small these days; 2GB is a better choice. 8) Then again, I work for a company that puts everything in /System/Library, so I guess I should be quiet now. 8) -- ... 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-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 12:44:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 5C72537B417; Sat, 8 Dec 2001 12:44:47 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fB8Ko1T01347; Sat, 8 Dec 2001 12:50:01 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112082050.fB8Ko1T01347@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: arch@FreeBSD.ORG Cc: Marko Zec , "Louis A. Mamakos" , Matthew Dillon , Sheldon Hearn , freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems In-reply-to: Your message of "Sat, 08 Dec 2001 10:26:58 PST." <20011208102658.B11428@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 Dec 2001 12:50:01 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > Why would we want to do that? Putting unnecessary things on / is always a > > bad idea, as root partition should remain small and as free of frequent RW > > operations as possible. > > That is a *PERSONAL* opinion, so please mark it as such. I personally > use 1.5GB / partitions. I _personally_ see zero reason for a /usr > partition. PERSONALLY, I disagree. 1.5GB is too small these days; 2GB is a better choice. 8) Then again, I work for a company that puts everything in /System/Library, so I guess I should be quiet now. 8) -- ... 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-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 12:55:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 6E96E37B42C; Sat, 8 Dec 2001 12:55:36 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB8Ktaf18457; Sat, 8 Dec 2001 12:55:36 -0800 (PST) (envelope-from dillon) Date: Sat, 8 Dec 2001 12:55:36 -0800 (PST) From: Matthew Dillon Message-Id: <200112082055.fB8Ktaf18457@apollo.backplane.com> To: Mike Smith Cc: arch@FreeBSD.ORG, Marko Zec , "Louis A. Mamakos" , Sheldon Hearn , freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems References: <200112082050.fB8Ko1T01347@mass.dis.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :PERSONALLY, I disagree. 1.5GB is too small these days; 2GB is a better :choice. 8) : :Then again, I work for a company that puts everything in /System/Library, :so I guess I should be quiet now. 8) My current patch set uses a 3G target. 2G is reasonable, but it cuts it fairly close if you do not have a separate /usr/obj and maintain builds for both -current and -stable (eats +1G!). Anything smaller then 2G is definitely too small. Maybe I should adjust the code so if the hard drive has a huge amount of space and all targets are met, it will further increase the size of certain partitions (/var, /var/tmp, /usr) to a new 'power' target. (we'll give /home a power target too so it doesn't get left out in the cold). However, I think I'll let the current patch set go through a commit round before I further complexify it. (I also need to add a /tmp softlink capability in a future commit round). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 12:56: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 6E96E37B42C; Sat, 8 Dec 2001 12:55:36 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB8Ktaf18457; Sat, 8 Dec 2001 12:55:36 -0800 (PST) (envelope-from dillon) Date: Sat, 8 Dec 2001 12:55:36 -0800 (PST) From: Matthew Dillon Message-Id: <200112082055.fB8Ktaf18457@apollo.backplane.com> To: Mike Smith Cc: arch@FreeBSD.ORG, Marko Zec , "Louis A. Mamakos" , Sheldon Hearn , freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems References: <200112082050.fB8Ko1T01347@mass.dis.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :PERSONALLY, I disagree. 1.5GB is too small these days; 2GB is a better :choice. 8) : :Then again, I work for a company that puts everything in /System/Library, :so I guess I should be quiet now. 8) My current patch set uses a 3G target. 2G is reasonable, but it cuts it fairly close if you do not have a separate /usr/obj and maintain builds for both -current and -stable (eats +1G!). Anything smaller then 2G is definitely too small. Maybe I should adjust the code so if the hard drive has a huge amount of space and all targets are met, it will further increase the size of certain partitions (/var, /var/tmp, /usr) to a new 'power' target. (we'll give /home a power target too so it doesn't get left out in the cold). However, I think I'll let the current patch set go through a commit round before I further complexify it. (I also need to add a /tmp softlink capability in a future commit round). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 13:15:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id 5F07237B405 for ; Sat, 8 Dec 2001 13:15:43 -0800 (PST) Received: from winston.freebsd.org (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id fB8LF8q49298; Sat, 8 Dec 2001 13:15:08 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: Matthew Dillon Cc: Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: Message from Matthew Dillon of "Fri, 07 Dec 2001 19:49:32 PST." <200112080349.fB83nWU00292@apollo.backplane.com> Date: Sat, 08 Dec 2001 13:15:08 -0800 Message-ID: <49294.1007846108@winston.freebsd.org> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Ok, I've finally gone and done it... cleaned up the sysinstall > 'Auto' option. OK, I have the following concerns with this: First I don't think that the concept of dynamic sizing and adding a bunch of extra default filesystems should be intermingled at all. I think they should be introduced one at a time and more gradually, both in order to obey the POLA since a lot of people (most?) use this feature and also because, for technical reasons, I think they're actually layered features and should be more carefully implemented if anyone's going to go down this road at all. To put it another way, I like the idea of more intelligent dynamic sizing for the existing set of default filesystems and would support that without reservation since the current set of default filesystems (/, /usr, /var) was rather deliberately chosen to represent the lowest common denominator of what a user might want *regardless* of the mission profile of the machine (OK, /var is currently too small for some missions, but that's orthogonal since we're not talking about the sizes, we're talking about the default set). I've also avoided addressing this feature for as long as I have because I knew that going to the next logical step would involve a lot more than just beefing up certain defaults and adding a few more filesystems to the mix - that would have been easy. The minute you take that easy out you also start making the configuration less generic and more mission specific, even if the mission is defined by your own biases as to what "generic" means. If you're going to go down that road at all then you might just as well admit from the start that what you need are multiple canned mission profiles and not just a single set of defaults which feel best to you but will probably just annoy a lot of other people. From a technical perspective, I think it could be handled by a little table structure that looked something like this: struct fs_item { char *name; /* mountpoint */ int min_size; /* minimum size of filesystem in MB */ int def_size; /* default size */ int size_inc; /* MB size increment to bump up or down */ }; struct disk_profile { char *name; /* "mail", "news", "desktop", etc.. */ char *long_desc; /* long description for menu */ struct fs_item members[0]; /* list of filesystems */ }; Then you could have: struct disk_profile profiles[] = { "mail", "A small-to-midsize mail server", { { "/tmp", 50, 100, 1 }, { "/var", 50, 100, 1 }, { "/var/spool", 200, 1000, 10 } }, "news", "A USENET news server", ... }; And allow the user to select a base profile from a menu or toggle through the available set with a keystroke if you want to make it available from the label editor. The lower-level code should then just take one of these structures as an input and shuffle things around until it can find the closest fit given the policy information it has to work with. I know this substantially expands the scope of the changes you're contemplating and I also know how easy it is to say (and irritating it is to hear) "that's not enough, you need to do a bunch more work before I'll be satisfied", but I really do feel that this is one of those features where you either have to keep things really simple and as policy-free as possible, as they more or less are now, or you need to go to a substantially higher level and apply more of an "expert system" type of approach if you want to make more decisions on behalf of the user. I don't see any middle positions with real value. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 14:11:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 9FB2937B419 for ; Sat, 8 Dec 2001 14:11:18 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB8MBGm18685; Sat, 8 Dec 2001 14:11:16 -0800 (PST) (envelope-from dillon) Date: Sat, 8 Dec 2001 14:11:16 -0800 (PST) From: Matthew Dillon Message-Id: <200112082211.fB8MBGm18685@apollo.backplane.com> To: Jordan Hubbard Cc: Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) References: <49294.1007846108@winston.freebsd.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hmm. Well, I have to disagree somewhat. 'A'uto isn't useful if the user has to think too much about it, and there is nothing preventing the user from deleting the partitions he doesn't want. /var/tmp and /home are fairly standard partition names... nothing new in my book. I certainly didn't invent them! In particular, these two partitions greatly increase the safety of the system... I can't count the number of times I've seen fsck *fail* on /var/tmp after a crash and was thankful that /var/tmp wasn't on /var. Not only that, but blowing-out /var/tmp is relatively easy to do even on a single user system. The last thing you want to see is a full /var/tmp causing your mail system to throw up rocks because it's on the same partition as /var. There is absolutely no sane reason to combine /var and /var/tmp together. The same thing goes for /home, though in /home's case the reasoning is somewhat more ephermal. You get the same safety factor in regards to having a greater chance of recovering /usr after a crash if /home isn't sitting in /usr (/usr/home) (or sitting in root for that matter!). (remember why /var was separated from /usr in the first place?). But you also have the added benefit of making /usr a managed space, limited to X amount (e.g. 3GB) and placing the remainder of your free space in /home. It makes far less sense to place the remainder of your free space in /usr. This setup works equally well as a default for both single and multi-user systems and also works fairly well for power-user and developer systems, and for most special-purpose systems except large special-purpose mail spools and repositories (which typically need a huge /var). It works far better as a default then simply creating /, /usr, and /var. In that light perhaps what we need to do is have an auto-resizing feature, so if the user deletes an auto-created partition sysinstall automatically resizes the auto-created partitions before it to fill up the space. So if the user hits 'A' and doesn't want /var/tmp, they simply delete /var/tmp and /var gets its space. And if they don't want /home they simply delete it and /usr gets its space. I think this is a much easier mechanism for the user then requiring him to select which Auto-profile to use. So despite your objections I am still leaning very heavily towards wanting to include /var/tmp and /home as defaults for the Auto option. -Matt :To put it another way, I like the idea of more intelligent dynamic :sizing for the existing set of default filesystems and would support :that without reservation since the current set of default filesystems :(/, /usr, /var) was rather deliberately chosen to represent the lowest :common denominator of what a user might want *regardless* of the :mission profile of the machine (OK, /var is currently too small for :some missions, but that's orthogonal since we're not talking about the :sizes, we're talking about the default set). : :I've also avoided addressing this feature for as long as I have :because I knew that going to the next logical step would involve a lot :more than just beefing up certain defaults and adding a few more :filesystems to the mix - that would have been easy. The minute you :take that easy out you also start making the configuration less :generic and more mission specific, even if the mission is defined by :your own biases as to what "generic" means. If you're going to go :down that road at all then you might just as well admit from the start :that what you need are multiple canned mission profiles and not just a :single set of defaults which feel best to you but will probably just :annoy a lot of other people. :... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 14:57: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id D9C5337B405; Sat, 8 Dec 2001 14:57:03 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB8MuwL19001; Sat, 8 Dec 2001 14:56:58 -0800 (PST) (envelope-from dillon) Date: Sat, 8 Dec 2001 14:56:58 -0800 (PST) From: Matthew Dillon Message-Id: <200112082256.fB8MuwL19001@apollo.backplane.com> To: Kirk McKusick Cc: Robert Watson , arch@FreeBSD.ORG Subject: Re: Default value for maxusers References: <200112071957.fB7Jvef29774@beastie.mckusick.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :I believe that we should do what BSD/OS did years ago. They default :maxusers to 0 which tells the system to size it at boot time based :on the amount of memory available on the system. Small memory machines :end up with a small value of maxusers and large memory machines ends :up with a large value of maxusers. In the rare case where the default :is wrong, the system administrator can set it to some non-zero value :which the kernel then uses. OK, how about this. Right now in GENERIC maxusers is set to 32. Lets make this the minimum. For a maximum (for the auto-sizing) I recommend a maxusers value of 512 @ 512M of physical ram. e.g. set maxusers to physical ram / one-megabyte, capped at 512 and never less then 32. The auto-maxusers would only apply if maxusers is set to 0 in the config. That's about 60 seconds worth of work in -stable and -current. Any objections? No?... Ok, I'll commit it today w/ a 1-week MFC :-) -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 15:40:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 3CCC937B41D; Sat, 8 Dec 2001 15:40:18 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB8NeI329704; Sat, 8 Dec 2001 15:40:18 -0800 (PST) (envelope-from dillon) Date: Sat, 8 Dec 2001 15:40:18 -0800 (PST) From: Matthew Dillon Message-Id: <200112082340.fB8NeI329704@apollo.backplane.com> To: Kirk McKusick , Robert Watson , arch@FreeBSD.ORG Subject: Patch for auto-default value for maxusers References: <200112071957.fB7Jvef29774@beastie.mckusick.com> <200112082256.fB8MuwL19001@apollo.backplane.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This patch is against -stable. It allows maxusers to be set to 0 in the kernel config. It will scale maxusers according to main memory, one per megabyte of main memory with a minimum of 32 and a maximum of 512. I did some preliminary testing of this patch (note: it also includes a page->kbyte fix for nbuf sizing). I had to reorder init_param() a bit because it was being called prior to physical memory sizing. A review of that would be nice. -Matt Index: usr.sbin/config/mkoptions.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/config/mkoptions.c,v retrieving revision 1.17.2.2 diff -u -r1.17.2.2 mkoptions.c --- usr.sbin/config/mkoptions.c 2000/11/21 20:03:38 1.17.2.2 +++ usr.sbin/config/mkoptions.c 2001/12/08 23:26:16 @@ -93,8 +93,8 @@ } else up = &users[machine - 1]; if (maxusers == 0) { - printf("maxusers not specified; %d assumed\n", up->u_default); - maxusers = up->u_default; + /* printf("maxusers not specified; will auto-size\n"); */ + maxusers = 0; } else if (maxusers < up->u_min) { printf("minimum of %d maxusers assumed\n", up->u_min); maxusers = up->u_min; Index: sys/alpha/alpha/machdep.c =================================================================== RCS file: /home/ncvs/src/sys/alpha/alpha/machdep.c,v retrieving revision 1.68.2.14 diff -u -r1.68.2.14 machdep.c --- sys/alpha/alpha/machdep.c 2001/10/04 13:09:36 1.68.2.14 +++ sys/alpha/alpha/machdep.c 2001/12/08 23:12:38 @@ -329,13 +329,14 @@ */ if (nbuf == 0) { - int factor = 4 * BKVASIZE / PAGE_SIZE; + int factor = 4 * BKVASIZE / 1024; + int kbytes = physmem * (PAGE_SIZE / 1024); nbuf = 50; - if (physmem > 1024) - nbuf += min((physmem - 1024) / factor, 16384 / factor); - if (physmem > 16384) - nbuf += (physmem - 16384) * 2 / (factor * 5); + if (kbytes > 4096) + nbuf += min((kbytes - 4096) / factor, 65536 / factor); + if (kbytes > 65536) + nbuf += (kbytes - 65536) * 2 / (factor * 5); if (maxbcache && nbuf > maxbcache / BKVASIZE) nbuf = maxbcache / BKVASIZE; } @@ -698,7 +699,7 @@ kern_envp = bootinfo.envp; /* Do basic tuning, hz etc */ - init_param(); + init_param1(); /* * Initalize the (temporary) bootstrap console interface, so @@ -1004,6 +1005,7 @@ physmem -= (sz - nsz); } } + init_param2(physmem); /* * Initialize error message buffer (at end of core). Index: sys/i386/i386/machdep.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v retrieving revision 1.385.2.20 diff -u -r1.385.2.20 machdep.c --- sys/i386/i386/machdep.c 2001/10/02 23:34:22 1.385.2.20 +++ sys/i386/i386/machdep.c 2001/12/08 23:11:09 @@ -331,13 +331,14 @@ * factor represents the 1/4 x ram conversion. */ if (nbuf == 0) { - int factor = 4 * BKVASIZE / PAGE_SIZE; + int factor = 4 * BKVASIZE / 1024; + int kbytes = physmem * (PAGE_SIZE / 1024); nbuf = 50; - if (physmem > 1024) - nbuf += min((physmem - 1024) / factor, 16384 / factor); - if (physmem > 16384) - nbuf += (physmem - 16384) * 2 / (factor * 5); + if (kbytes > 4096) + nbuf += min((kbytes - 4096) / factor, 65536 / factor); + if (kbytes > 65536) + nbuf += (kbytes - 65536) * 2 / (factor * 5); if (maxbcache && nbuf > maxbcache / BKVASIZE) nbuf = maxbcache / BKVASIZE; } @@ -1829,7 +1830,7 @@ kern_envp = (caddr_t)bootinfo.bi_envp + KERNBASE; /* Init basic tunables, hz etc */ - init_param(); + init_param1(); /* * make gdt memory segments, the code segment goes up to end of the @@ -1963,6 +1964,7 @@ vm86_initialize(); getmemsize(first); + init_param2(physmem); /* now running on new page tables, configured,and u/iom is accessible */ Index: sys/kern/subr_param.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_param.c,v retrieving revision 1.42.2.3 diff -u -r1.42.2.3 subr_param.c --- sys/kern/subr_param.c 2001/11/03 01:41:08 1.42.2.3 +++ sys/kern/subr_param.c 2001/12/08 23:28:49 @@ -98,33 +98,16 @@ struct buf *swbuf; /* - * Boot time overrides + * Boot time overrides that are not scaled against main memory */ void -init_param(void) +init_param1(void) { - - /* Base parameters */ - maxusers = MAXUSERS; - TUNABLE_INT_FETCH("kern.maxusers", &maxusers); hz = HZ; TUNABLE_INT_FETCH("kern.hz", &hz); tick = 1000000 / hz; tickadj = howmany(30000, 60 * hz); /* can adjust 30ms in 60s */ - /* The following can be overridden after boot via sysctl */ - maxproc = NPROC; - TUNABLE_INT_FETCH("kern.maxproc", &maxproc); - maxfiles = MAXFILES; - TUNABLE_INT_FETCH("kern.maxfiles", &maxfiles); - maxprocperuid = maxproc - 1; - maxfilesperproc = maxfiles; - - /* Cannot be changed after boot */ - nsfbufs = NSFBUFS; - TUNABLE_INT_FETCH("kern.ipc.nsfbufs", &nsfbufs); - nbuf = NBUF; - TUNABLE_INT_FETCH("kern.nbuf", &nbuf); #ifdef VM_SWZONE_SIZE_MAX maxswzone = VM_SWZONE_SIZE_MAX; #endif @@ -133,8 +116,6 @@ maxbcache = VM_BCACHE_SIZE_MAX; #endif TUNABLE_INT_FETCH("kern.maxbcache", &maxbcache); - ncallout = 16 + maxproc + maxfiles; - TUNABLE_INT_FETCH("kern.ncallout", &ncallout); maxtsiz = MAXTSIZ; TUNABLE_QUAD_FETCH("kern.maxtsiz", &maxtsiz); @@ -149,3 +130,45 @@ sgrowsiz = SGROWSIZ; TUNABLE_QUAD_FETCH("kern.sgrowsiz", &sgrowsiz); } + +/* + * Boot time overrides that are scaled against main memory + */ +void +init_param2(int physpages) +{ + + /* Base parameters */ + if ((maxusers = MAXUSERS) == 0) { + maxusers = physpages / (1024 * 1024 / PAGE_SIZE); + if (maxusers < 32) + maxusers = 32; + if (maxusers > 512) + maxusers = 512; + } + TUNABLE_INT_FETCH("kern.maxusers", &maxusers); + + /* + * The following can be overridden after boot via sysctl. Note: + * unless overriden, these macros are ultimately based on maxusers. + */ + maxproc = NPROC; + TUNABLE_INT_FETCH("kern.maxproc", &maxproc); + maxfiles = MAXFILES; + TUNABLE_INT_FETCH("kern.maxfiles", &maxfiles); + maxprocperuid = maxproc - 1; + maxfilesperproc = maxfiles; + + /* + * Cannot be changed after boot. Unless overriden, NSFBUFS is based + * on maxusers and NBUF is typically 0 (auto-sized later). + */ + nsfbufs = NSFBUFS; + TUNABLE_INT_FETCH("kern.ipc.nsfbufs", &nsfbufs); + nbuf = NBUF; + TUNABLE_INT_FETCH("kern.nbuf", &nbuf); + + ncallout = 16 + maxproc + maxfiles; + TUNABLE_INT_FETCH("kern.ncallout", &ncallout); +} + Index: sys/pc98/i386/machdep.c =================================================================== RCS file: /home/ncvs/src/sys/pc98/i386/machdep.c,v retrieving revision 1.151.2.23 diff -u -r1.151.2.23 machdep.c --- sys/pc98/i386/machdep.c 2001/10/08 03:29:43 1.151.2.23 +++ sys/pc98/i386/machdep.c 2001/12/08 23:13:11 @@ -344,13 +344,14 @@ * factor represents the 1/4 x ram conversion. */ if (nbuf == 0) { - int factor = 4 * BKVASIZE / PAGE_SIZE; + int factor = 4 * BKVASIZE / 1024; + int kbytes = physmem * (PAGE_SIZE / 1024); nbuf = 50; - if (physmem > 1024) - nbuf += min((physmem - 1024) / factor, 16384 / factor); - if (physmem > 16384) - nbuf += (physmem - 16384) * 2 / (factor * 5); + if (kbytes > 4096) + nbuf += min((kbytes - 4096) / factor, 65536 / factor); + if (kbytes > 65536) + nbuf += (kbytes - 65536) * 2 / (factor * 5); if (maxbcache && nbuf > maxbcache / BKVASIZE) nbuf = maxbcache / BKVASIZE; } @@ -1880,7 +1881,7 @@ kern_envp = (caddr_t)bootinfo.bi_envp + KERNBASE; /* Init basic tunables, hz etc */ - init_param(); + init_param1(); /* * make gdt memory segments, the code segment goes up to end of the @@ -2014,6 +2015,7 @@ vm86_initialize(); getmemsize(first); + init_param2(physmem); /* now running on new page tables, configured,and u/iom is accessible */ Index: sys/sys/systm.h =================================================================== RCS file: /home/ncvs/src/sys/sys/systm.h,v retrieving revision 1.111.2.11 diff -u -r1.111.2.11 systm.h --- sys/sys/systm.h 2001/12/04 05:57:40 1.111.2.11 +++ sys/sys/systm.h 2001/12/08 23:13:35 @@ -126,7 +126,8 @@ void cpu_boot __P((int)); void cpu_rootconf __P((void)); -void init_param __P((void)); +void init_param1 __P((void)); +void init_param2 __P((int physpages)); void tablefull __P((const char *)); int addlog __P((const char *, ...)) __printflike(1, 2); int kvprintf __P((char const *, void (*)(int, void*), void *, int, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 16: 5:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 46C9837B417 for ; Sat, 8 Dec 2001 16:05:05 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.0/8.11.0) with UUCP id fB9050w65395; Sun, 9 Dec 2001 01:05:00 +0100 (CET) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id fB8NcWtx059472; Sun, 9 Dec 2001 00:38:32 +0100 (CET)?g (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id fB8NcVW02159; Sun, 9 Dec 2001 00:38:31 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.6/8.11.6) id fB8NcTZ06829; Sun, 9 Dec 2001 00:38:29 +0100 (CET) (envelope-from ticso) Date: Sun, 9 Dec 2001 00:38:29 +0100 From: Bernd Walter To: Wilko Bulte Cc: Matthew Dillon , "David O'Brien" , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) Message-ID: <20011209003829.C6171@cicely8.cicely.de> References: <31807.1007732134@axl.seasidesoftware.co.za> <200112072257.fB7MvjE95211@apollo.backplane.com> <200112072311.fB7NB2723789@whizzo.transsys.com> <200112080349.fB83nWU00292@apollo.backplane.com> <20011208103048.C11428@dragon.nuxi.com> <200112081911.fB8JBTW06147@apollo.backplane.com> <20011208205131.A56648@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011208205131.A56648@freebie.xs4all.nl> User-Agent: Mutt/1.3.23i X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Dec 08, 2001 at 08:51:31PM +0100, Wilko Bulte wrote: > On Sat, Dec 08, 2001 at 11:11:29AM -0800, Matthew Dillon wrote: > > > > : > > :On Fri, Dec 07, 2001 at 07:49:32PM -0800, Matthew Dillon wrote: > > :> We do not have enough partition id's to make a separate > > :> /usr/local. > > : > > :Has anyone considered raising the max number of partitions from 8 to 16 > > :as OpenBSD did years ago? > > > > Oh, by the way... there is actually a way you can bump up the number > > of partitions. What you do is split the disk up into multiple slices. > > We have 4, after all. You can then disklabel each one. > > This works on x86 but not on alpha which does not use slices. Vinum works fine on i386 and alpha. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 16:33:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 2B21F37B41C for ; Sat, 8 Dec 2001 16:33:52 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.0/8.11.0) with UUCP id fB90XXw65600; Sun, 9 Dec 2001 01:33:34 +0100 (CET) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id fB90Xhtx059821; Sun, 9 Dec 2001 01:33:43 +0100 (CET)?g (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id fB90XhW02198; Sun, 9 Dec 2001 01:33:43 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.6/8.11.6) id fB90XeL06957; Sun, 9 Dec 2001 01:33:40 +0100 (CET) (envelope-from ticso) Date: Sun, 9 Dec 2001 01:33:40 +0100 From: Bernd Walter To: Matthew Dillon Cc: Jordan Hubbard , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) Message-ID: <20011209013340.D6171@cicely8.cicely.de> References: <49294.1007846108@winston.freebsd.org> <200112082211.fB8MBGm18685@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200112082211.fB8MBGm18685@apollo.backplane.com> User-Agent: Mutt/1.3.23i X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Dec 08, 2001 at 02:11:16PM -0800, Matthew Dillon wrote: > Hmm. Well, I have to disagree somewhat. 'A'uto isn't useful if > the user has to think too much about it, and there is nothing > preventing the user from deleting the partitions he doesn't want. > /var/tmp and /home are fairly standard partition names... nothing > new in my book. I certainly didn't invent them! In particular, > these two partitions greatly increase the safety of the system... I > can't count the number of times I've seen fsck *fail* on /var/tmp > after a crash and was thankful that /var/tmp wasn't on /var. I hate if Software writes on /var/tmp instead of /tmp. I don't need an fsck on /tmp because it's md/mfs based - or if you like for performance reasons newfs the partition at boot. /var/tmp should be used for files that should survive a reboot like vi.recover and nothing else. FreeBSD still ships with /usr/share/doc/smm/01.setup/paper.ascii.gz where /tmp is said to be MFS based and /var/tmp disk based. > Not only that, but blowing-out /var/tmp is relatively easy to do even > on a single user system. The last thing you want to see is a full Not surprising with a softlink from /tmp to /var/tmp. > /var/tmp causing your mail system to throw up rocks because it's on > the same partition as /var. There is absolutely no sane reason to > combine /var and /var/tmp together. There is more than that - think of /var/spool/lpd or /var/log. If you want it save then create a /var/mail and /var/spool partition. > The same thing goes for /home, though in /home's case the reasoning > is somewhat more ephermal. You get the same safety factor in regards > to having a greater chance of recovering /usr after a crash if /home > isn't sitting in /usr (/usr/home) (or sitting in root for that matter!). The traditional directory is /var/users but I prefer /var/home. If you don't want a separate /home partition /var/users is the better choice. /home is the place for system wide home directories which are usualy non-local - therefor no need for a local partition. I agree that /usr/home is bad idea. > (remember why /var was separated from /usr in the first place?). > But you also have the added benefit of making /usr a managed space, > limited to X amount (e.g. 3GB) and placing the remainder of your free > space in /home. It makes far less sense to place the remainder of > your free space in /usr. Right - it's administered so if space go out the administrator can always mount additional space under /usr. That's the same reason I usually softlink /usr/ports to /var/ports as it can easily blow space. Uh Softlinks are remembered by some programms so /home softlink doesn't work perfect. It's the same reason I don't like software using /compat instead of /usr/compat. /var is my definition of whats left after creating /, /usr and what additionally needed. > This setup works equally well as a default for both single and > multi-user systems and also works fairly well for power-user > and developer systems, and for most special-purpose systems > except large special-purpose mail spools and repositories (which > typically need a huge /var). It works far better as a default > then simply creating /, /usr, and /var. > > In that light perhaps what we need to do is have an auto-resizing > feature, so if the user deletes an auto-created partition sysinstall > automatically resizes the auto-created partitions before it to fill > up the space. So if the user hits 'A' and doesn't want /var/tmp, they > simply delete /var/tmp and /var gets its space. And if they don't > want /home they simply delete it and /usr gets its space. I think > this is a much easier mechanism for the user then requiring him to > select which Auto-profile to use. The auto-resizing part is realy a missing feature. > So despite your objections I am still leaning very heavily towards > wanting to include /var/tmp and /home as defaults for the Auto option. A home default is a good idea but I don't like it in / for the reasons above. It's also easier for a possible autoresize to add /var/users to /var instead of having a completely different path. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 16:53:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 655E737B417 for ; Sat, 8 Dec 2001 16:53:19 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id RAA00943; Sat, 8 Dec 2001 17:52:32 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id fB90qV077939; Sat, 8 Dec 2001 17:52:31 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15378.46543.229258.473566@caddis.yogotech.com> Date: Sat, 8 Dec 2001 17:52:31 -0700 To: Matthew Dillon Cc: Jordan Hubbard , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: <200112082211.fB8MBGm18685@apollo.backplane.com> References: <49294.1007846108@winston.freebsd.org> <200112082211.fB8MBGm18685@apollo.backplane.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Not only that, but blowing-out /var/tmp is relatively easy to do even > on a single user system. I've *NEVER* done, and the only thing that's blown out /var on any machine I've ever used is /var/log. That's about 8+ years of experience and 200-300 different boxes. > The last thing you want to see is a full > /var/tmp causing your mail system to throw up rocks because it's on > the same partition as /var. There is absolutely no sane reason to > combine /var and /var/tmp together. Obviously, I disagree. Therefore, I aree with Jordan and suggest that your 'bias' is based on your experience, which may differ from others. > The same thing goes for /home, though in /home's case the reasoning > is somewhat more ephermal. One single-user systems, I create /usr/home, and symlink /home to it. However, that's a personal preference I don't suggest is valid for everyone. One larger systems, I usually allocate an entire disk to /home, but again, that's a personal preference, and one that I don't think should be hard-coded as a good default. (Especially since sysinstall's main goal is to get a minimal system installed on the system.) I think many of the changes you've done are very good. I just disagree that the default partitioning scheme of '/','/var', and '/usr' isn't adequate for a 'base' configuration. As David and others have pointed out, they like monstrous '/' partitions which I shudder to think about when crashes occur. In short, I think we should stick with the current 3 partition base setup for 'automatic', and let others which *really* need more than automatic to create their own, or otherwise extend it to have different classes of 'auto' configurations as Jordan suggested. (Back to my hole.....) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 16:54:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id EE46D37B419; Sat, 8 Dec 2001 16:54:10 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id RAA01015; Sat, 8 Dec 2001 17:54:06 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id fB90s6m77949; Sat, 8 Dec 2001 17:54:06 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15378.46638.217290.407771@caddis.yogotech.com> Date: Sat, 8 Dec 2001 17:54:06 -0700 To: Matthew Dillon Cc: Kirk McKusick , Robert Watson , arch@FreeBSD.ORG Subject: Re: Patch for auto-default value for maxusers In-Reply-To: <200112082340.fB8NeI329704@apollo.backplane.com> References: <200112071957.fB7Jvef29774@beastie.mckusick.com> <200112082256.fB8MuwL19001@apollo.backplane.com> <200112082340.fB8NeI329704@apollo.backplane.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > This patch is against -stable. Minor nit... > > Index: usr.sbin/config/mkoptions.c > =================================================================== > RCS file: /home/ncvs/src/usr.sbin/config/mkoptions.c,v > retrieving revision 1.17.2.2 > diff -u -r1.17.2.2 mkoptions.c > --- usr.sbin/config/mkoptions.c 2000/11/21 20:03:38 1.17.2.2 > +++ usr.sbin/config/mkoptions.c 2001/12/08 23:26:16 > @@ -93,8 +93,8 @@ > } else > up = &users[machine - 1]; > if (maxusers == 0) { > - printf("maxusers not specified; %d assumed\n", up->u_default); > - maxusers = up->u_default; > + /* printf("maxusers not specified; will auto-size\n"); */ > + maxusers = 0; Isn't this line kind of redundant, since we already know that maxusers == 0? > } else if (maxusers < up->u_min) { > printf("minimum of %d maxusers assumed\n", up->u_min); > maxusers = up->u_min; > Index: sys/alpha/alpha/machdep.c > =================================================================== > RCS file: /home/ncvs/src/sys/alpha/alpha/machdep.c,v > retrieving revision 1.68.2.14 > diff -u -r1.68.2.14 machdep.c > --- sys/alpha/alpha/machdep.c 2001/10/04 13:09:36 1.68.2.14 > +++ sys/alpha/alpha/machdep.c 2001/12/08 23:12:38 > @@ -329,13 +329,14 @@ > */ > > if (nbuf == 0) { > - int factor = 4 * BKVASIZE / PAGE_SIZE; > + int factor = 4 * BKVASIZE / 1024; > + int kbytes = physmem * (PAGE_SIZE / 1024); > > nbuf = 50; > - if (physmem > 1024) > - nbuf += min((physmem - 1024) / factor, 16384 / factor); > - if (physmem > 16384) > - nbuf += (physmem - 16384) * 2 / (factor * 5); > + if (kbytes > 4096) > + nbuf += min((kbytes - 4096) / factor, 65536 / factor); > + if (kbytes > 65536) > + nbuf += (kbytes - 65536) * 2 / (factor * 5); > if (maxbcache && nbuf > maxbcache / BKVASIZE) > nbuf = maxbcache / BKVASIZE; > } > @@ -698,7 +699,7 @@ > kern_envp = bootinfo.envp; > > /* Do basic tuning, hz etc */ > - init_param(); > + init_param1(); > > /* > * Initalize the (temporary) bootstrap console interface, so > @@ -1004,6 +1005,7 @@ > physmem -= (sz - nsz); > } > } > + init_param2(physmem); > > /* > * Initialize error message buffer (at end of core). > Index: sys/i386/i386/machdep.c > =================================================================== > RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v > retrieving revision 1.385.2.20 > diff -u -r1.385.2.20 machdep.c > --- sys/i386/i386/machdep.c 2001/10/02 23:34:22 1.385.2.20 > +++ sys/i386/i386/machdep.c 2001/12/08 23:11:09 > @@ -331,13 +331,14 @@ > * factor represents the 1/4 x ram conversion. > */ > if (nbuf == 0) { > - int factor = 4 * BKVASIZE / PAGE_SIZE; > + int factor = 4 * BKVASIZE / 1024; > + int kbytes = physmem * (PAGE_SIZE / 1024); > > nbuf = 50; > - if (physmem > 1024) > - nbuf += min((physmem - 1024) / factor, 16384 / factor); > - if (physmem > 16384) > - nbuf += (physmem - 16384) * 2 / (factor * 5); > + if (kbytes > 4096) > + nbuf += min((kbytes - 4096) / factor, 65536 / factor); > + if (kbytes > 65536) > + nbuf += (kbytes - 65536) * 2 / (factor * 5); > if (maxbcache && nbuf > maxbcache / BKVASIZE) > nbuf = maxbcache / BKVASIZE; > } > @@ -1829,7 +1830,7 @@ > kern_envp = (caddr_t)bootinfo.bi_envp + KERNBASE; > > /* Init basic tunables, hz etc */ > - init_param(); > + init_param1(); > > /* > * make gdt memory segments, the code segment goes up to end of the > @@ -1963,6 +1964,7 @@ > > vm86_initialize(); > getmemsize(first); > + init_param2(physmem); > > /* now running on new page tables, configured,and u/iom is accessible */ > > Index: sys/kern/subr_param.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/subr_param.c,v > retrieving revision 1.42.2.3 > diff -u -r1.42.2.3 subr_param.c > --- sys/kern/subr_param.c 2001/11/03 01:41:08 1.42.2.3 > +++ sys/kern/subr_param.c 2001/12/08 23:28:49 > @@ -98,33 +98,16 @@ > struct buf *swbuf; > > /* > - * Boot time overrides > + * Boot time overrides that are not scaled against main memory > */ > void > -init_param(void) > +init_param1(void) > { > - > - /* Base parameters */ > - maxusers = MAXUSERS; > - TUNABLE_INT_FETCH("kern.maxusers", &maxusers); > hz = HZ; > TUNABLE_INT_FETCH("kern.hz", &hz); > tick = 1000000 / hz; > tickadj = howmany(30000, 60 * hz); /* can adjust 30ms in 60s */ > > - /* The following can be overridden after boot via sysctl */ > - maxproc = NPROC; > - TUNABLE_INT_FETCH("kern.maxproc", &maxproc); > - maxfiles = MAXFILES; > - TUNABLE_INT_FETCH("kern.maxfiles", &maxfiles); > - maxprocperuid = maxproc - 1; > - maxfilesperproc = maxfiles; > - > - /* Cannot be changed after boot */ > - nsfbufs = NSFBUFS; > - TUNABLE_INT_FETCH("kern.ipc.nsfbufs", &nsfbufs); > - nbuf = NBUF; > - TUNABLE_INT_FETCH("kern.nbuf", &nbuf); > #ifdef VM_SWZONE_SIZE_MAX > maxswzone = VM_SWZONE_SIZE_MAX; > #endif > @@ -133,8 +116,6 @@ > maxbcache = VM_BCACHE_SIZE_MAX; > #endif > TUNABLE_INT_FETCH("kern.maxbcache", &maxbcache); > - ncallout = 16 + maxproc + maxfiles; > - TUNABLE_INT_FETCH("kern.ncallout", &ncallout); > > maxtsiz = MAXTSIZ; > TUNABLE_QUAD_FETCH("kern.maxtsiz", &maxtsiz); > @@ -149,3 +130,45 @@ > sgrowsiz = SGROWSIZ; > TUNABLE_QUAD_FETCH("kern.sgrowsiz", &sgrowsiz); > } > + > +/* > + * Boot time overrides that are scaled against main memory > + */ > +void > +init_param2(int physpages) > +{ > + > + /* Base parameters */ > + if ((maxusers = MAXUSERS) == 0) { > + maxusers = physpages / (1024 * 1024 / PAGE_SIZE); > + if (maxusers < 32) > + maxusers = 32; > + if (maxusers > 512) > + maxusers = 512; > + } > + TUNABLE_INT_FETCH("kern.maxusers", &maxusers); > + > + /* > + * The following can be overridden after boot via sysctl. Note: > + * unless overriden, these macros are ultimately based on maxusers. > + */ > + maxproc = NPROC; > + TUNABLE_INT_FETCH("kern.maxproc", &maxproc); > + maxfiles = MAXFILES; > + TUNABLE_INT_FETCH("kern.maxfiles", &maxfiles); > + maxprocperuid = maxproc - 1; > + maxfilesperproc = maxfiles; > + > + /* > + * Cannot be changed after boot. Unless overriden, NSFBUFS is based > + * on maxusers and NBUF is typically 0 (auto-sized later). > + */ > + nsfbufs = NSFBUFS; > + TUNABLE_INT_FETCH("kern.ipc.nsfbufs", &nsfbufs); > + nbuf = NBUF; > + TUNABLE_INT_FETCH("kern.nbuf", &nbuf); > + > + ncallout = 16 + maxproc + maxfiles; > + TUNABLE_INT_FETCH("kern.ncallout", &ncallout); > +} > + > Index: sys/pc98/i386/machdep.c > =================================================================== > RCS file: /home/ncvs/src/sys/pc98/i386/machdep.c,v > retrieving revision 1.151.2.23 > diff -u -r1.151.2.23 machdep.c > --- sys/pc98/i386/machdep.c 2001/10/08 03:29:43 1.151.2.23 > +++ sys/pc98/i386/machdep.c 2001/12/08 23:13:11 > @@ -344,13 +344,14 @@ > * factor represents the 1/4 x ram conversion. > */ > if (nbuf == 0) { > - int factor = 4 * BKVASIZE / PAGE_SIZE; > + int factor = 4 * BKVASIZE / 1024; > + int kbytes = physmem * (PAGE_SIZE / 1024); > > nbuf = 50; > - if (physmem > 1024) > - nbuf += min((physmem - 1024) / factor, 16384 / factor); > - if (physmem > 16384) > - nbuf += (physmem - 16384) * 2 / (factor * 5); > + if (kbytes > 4096) > + nbuf += min((kbytes - 4096) / factor, 65536 / factor); > + if (kbytes > 65536) > + nbuf += (kbytes - 65536) * 2 / (factor * 5); > if (maxbcache && nbuf > maxbcache / BKVASIZE) > nbuf = maxbcache / BKVASIZE; > } > @@ -1880,7 +1881,7 @@ > kern_envp = (caddr_t)bootinfo.bi_envp + KERNBASE; > > /* Init basic tunables, hz etc */ > - init_param(); > + init_param1(); > > /* > * make gdt memory segments, the code segment goes up to end of the > @@ -2014,6 +2015,7 @@ > > vm86_initialize(); > getmemsize(first); > + init_param2(physmem); > > /* now running on new page tables, configured,and u/iom is accessible */ > > Index: sys/sys/systm.h > =================================================================== > RCS file: /home/ncvs/src/sys/sys/systm.h,v > retrieving revision 1.111.2.11 > diff -u -r1.111.2.11 systm.h > --- sys/sys/systm.h 2001/12/04 05:57:40 1.111.2.11 > +++ sys/sys/systm.h 2001/12/08 23:13:35 > @@ -126,7 +126,8 @@ > > void cpu_boot __P((int)); > void cpu_rootconf __P((void)); > -void init_param __P((void)); > +void init_param1 __P((void)); > +void init_param2 __P((int physpages)); > void tablefull __P((const char *)); > int addlog __P((const char *, ...)) __printflike(1, 2); > int kvprintf __P((char const *, void (*)(int, void*), void *, int, > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 16:57:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 7F8FD37B420 for ; Sat, 8 Dec 2001 16:57:33 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011209005723.LNHD5859.rwcrmhc51.attbi.com@peter3.wemm.org> for ; Sun, 9 Dec 2001 00:57:23 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id fB90vWs28169 for ; Sat, 8 Dec 2001 16:57:32 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 019053808; Sat, 8 Dec 2001 16:57:32 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Bernd Walter Cc: Wilko Bulte , Matthew Dillon , "David O'Brien" , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: <20011209003829.C6171@cicely8.cicely.de> Date: Sat, 08 Dec 2001 16:57:31 -0800 From: Peter Wemm Message-Id: <20011209005732.019053808@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bernd Walter wrote: > On Sat, Dec 08, 2001 at 08:51:31PM +0100, Wilko Bulte wrote: > > On Sat, Dec 08, 2001 at 11:11:29AM -0800, Matthew Dillon wrote: > > > > > > : > > > :On Fri, Dec 07, 2001 at 07:49:32PM -0800, Matthew Dillon wrote: > > > :> We do not have enough partition id's to make a separate > > > :> /usr/local. > > > : > > > :Has anyone considered raising the max number of partitions from 8 to 16 > > > :as OpenBSD did years ago? > > > > > > Oh, by the way... there is actually a way you can bump up the number > > > of partitions. What you do is split the disk up into multiple slices . > > > We have 4, after all. You can then disklabel each one. > > > > This works on x86 but not on alpha which does not use slices. > > Vinum works fine on i386 and alpha. Yes, but vinum brings its own problems. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 17: 1:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 852AB37B405; Sat, 8 Dec 2001 17:01:43 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB911BB87688; Sat, 8 Dec 2001 17:01:11 -0800 (PST) (envelope-from dillon) Date: Sat, 8 Dec 2001 17:01:11 -0800 (PST) From: Matthew Dillon Message-Id: <200112090101.fB911BB87688@apollo.backplane.com> To: Nate Williams Cc: Kirk McKusick , Robert Watson , arch@FreeBSD.ORG Subject: Re: Patch for auto-default value for maxusers References: <200112071957.fB7Jvef29774@beastie.mckusick.com> <200112082256.fB8MuwL19001@apollo.backplane.com> <200112082340.fB8NeI329704@apollo.backplane.com> <15378.46638.217290.407771@caddis.yogotech.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :> This patch is against -stable. : :Minor nit... Yes, well, you can blame -current's buildkernel mechanism for not rebuilding config, buildworld not being able to handle -DNOCLEAN without barfing, and the whole fraggin build mechanism for not being able to build one fragging -current binary on a -stable machine. :> - maxusers = up->u_default; :> + /* printf("maxusers not specified; will auto-size\n"); */ :> + maxusers = 0; : :Isn't this line kind of redundant, since we already know that maxusers == 0? Yah. It's just a preliminary patch. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 17: 2:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id DBB2E37B41B; Sat, 8 Dec 2001 17:02:12 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011209010212.KSBF24045.rwcrmhc53.attbi.com@peter3.wemm.org>; Sun, 9 Dec 2001 01:02:12 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id fB912Cs28219; Sat, 8 Dec 2001 17:02:12 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 174073810; Sat, 8 Dec 2001 17:02:12 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Mike Smith Cc: arch@FreeBSD.ORG, Marko Zec , "Louis A. Mamakos" , Matthew Dillon , Sheldon Hearn , freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems In-Reply-To: <200112082050.fB8Ko1T01347@mass.dis.org> Date: Sat, 08 Dec 2001 17:02:12 -0800 From: Peter Wemm Message-Id: <20011209010212.174073810@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Smith wrote: > > > Why would we want to do that? Putting unnecessary things on / is always a > > > bad idea, as root partition should remain small and as free of frequent R W > > > operations as possible. > > > > That is a *PERSONAL* opinion, so please mark it as such. I personally > > use 1.5GB / partitions. I _personally_ see zero reason for a /usr > > partition. > > PERSONALLY, I disagree. 1.5GB is too small these days; 2GB is a better > choice. 8) Heh, what sort of crud do you put in /usr/local? :-) I usually use 512M for /usr, and sometimes 1G if the machine is going to run X. But I dont put src, obj or ports in there. /usr/obj has no business being in /usr in the first place IMHO. I symlink /usr/obj, /usr/src, /usr/ports and /var/ crash to /home/$dirname. But then again, I usually dont use sysinstall at all for installing new systems at home. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 17: 2:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id DBB2E37B41B; Sat, 8 Dec 2001 17:02:12 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011209010212.KSBF24045.rwcrmhc53.attbi.com@peter3.wemm.org>; Sun, 9 Dec 2001 01:02:12 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id fB912Cs28219; Sat, 8 Dec 2001 17:02:12 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 174073810; Sat, 8 Dec 2001 17:02:12 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Mike Smith Cc: arch@FreeBSD.ORG, Marko Zec , "Louis A. Mamakos" , Matthew Dillon , Sheldon Hearn , freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems In-Reply-To: <200112082050.fB8Ko1T01347@mass.dis.org> Date: Sat, 08 Dec 2001 17:02:12 -0800 From: Peter Wemm Message-Id: <20011209010212.174073810@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Smith wrote: > > > Why would we want to do that? Putting unnecessary things on / is always a > > > bad idea, as root partition should remain small and as free of frequent R W > > > operations as possible. > > > > That is a *PERSONAL* opinion, so please mark it as such. I personally > > use 1.5GB / partitions. I _personally_ see zero reason for a /usr > > partition. > > PERSONALLY, I disagree. 1.5GB is too small these days; 2GB is a better > choice. 8) Heh, what sort of crud do you put in /usr/local? :-) I usually use 512M for /usr, and sometimes 1G if the machine is going to run X. But I dont put src, obj or ports in there. /usr/obj has no business being in /usr in the first place IMHO. I symlink /usr/obj, /usr/src, /usr/ports and /var/ crash to /home/$dirname. But then again, I usually dont use sysinstall at all for installing new systems at home. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 17:55:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 2D2CD37B405 for ; Sat, 8 Dec 2001 17:55:38 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.0/8.11.0) with UUCP id fB91taR66017; Sun, 9 Dec 2001 02:55:36 +0100 (CET) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id fB91tstx060282; Sun, 9 Dec 2001 02:55:54 +0100 (CET)?g (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id fB91trW02254; Sun, 9 Dec 2001 02:55:53 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.6/8.11.6) id fB91tmt07150; Sun, 9 Dec 2001 02:55:48 +0100 (CET) (envelope-from ticso) Date: Sun, 9 Dec 2001 02:55:47 +0100 From: Bernd Walter To: Peter Wemm Cc: Wilko Bulte , Matthew Dillon , "David O'Brien" , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) Message-ID: <20011209025547.B7042@cicely8.cicely.de> References: <20011209003829.C6171@cicely8.cicely.de> <20011209005732.019053808@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011209005732.019053808@overcee.netplex.com.au> User-Agent: Mutt/1.3.23i X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Dec 08, 2001 at 04:57:31PM -0800, Peter Wemm wrote: > Bernd Walter wrote: > > Vinum works fine on i386 and alpha. > > Yes, but vinum brings its own problems. Right - sysinstall doesn't know it. I usually work around by having 200M /, >=1M swap and 500M /usr. After installation I put the rest into vinum, move /usr and /var onto vinum volumes and resize swap to include the transition /usr. Even if you don't move /usr and /var later - there is no need to create a home, www or whatever partition within sysinstall. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 18:23:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id C8B1A37B41C for ; Sat, 8 Dec 2001 18:23:20 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB92NKf34327; Sat, 8 Dec 2001 18:23:20 -0800 (PST) (envelope-from dillon) Date: Sat, 8 Dec 2001 18:23:20 -0800 (PST) From: Matthew Dillon Message-Id: <200112090223.fB92NKf34327@apollo.backplane.com> To: Bernd Walter , Peter Wemm , Wilko Bulte , "David O'Brien" , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) References: <20011209003829.C6171@cicely8.cicely.de> <20011209005732.019053808@overcee.netplex.com.au> <20011209025547.B7042@cicely8.cicely.de> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sigh. Well, I guess it was a mistake in believing that you guys would actually write considered responses to the list (except for Jordan who while I don't agree with his position, at least took some time to think about the issue). Lets see, what have I heard so far? Jordan wants a major generification of the mechanism (about a 3 man-day's worth of work. At least). Peter and Bernd are posting their favorite (and apparently extremely complex and non-standard) partitioning methodologies, neither of which is even close to being appropriate for sysinstall, and Nate... well, Nate means well, but I was hoping for a review of the init_param*() split, not a critique of minor syntax. Ah well. Perhaps my expectations were a little too high. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 19:12:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 89EC637B416 for ; Sat, 8 Dec 2001 19:12:43 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.0/8.11.0) with UUCP id fB93Ceb67567; Sun, 9 Dec 2001 04:12:40 +0100 (CET) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id fB93Cutx060915; Sun, 9 Dec 2001 04:12:56 +0100 (CET)?g (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id fB93CtW02970; Sun, 9 Dec 2001 04:12:55 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.6/8.11.6) id fB93CnG07544; Sun, 9 Dec 2001 04:12:49 +0100 (CET) (envelope-from ticso) Date: Sun, 9 Dec 2001 04:12:49 +0100 From: Bernd Walter To: Matthew Dillon Cc: Peter Wemm , Wilko Bulte , "David O'Brien" , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) Message-ID: <20011209041249.D7042@cicely8.cicely.de> References: <20011209003829.C6171@cicely8.cicely.de> <20011209005732.019053808@overcee.netplex.com.au> <20011209025547.B7042@cicely8.cicely.de> <200112090223.fB92NKf34327@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200112090223.fB92NKf34327@apollo.backplane.com> User-Agent: Mutt/1.3.23i X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Dec 08, 2001 at 06:23:20PM -0800, Matthew Dillon wrote: > Sigh. Well, I guess it was a mistake in believing that you guys > would actually write considered responses to the list (except > for Jordan who while I don't agree with his position, at least > took some time to think about the issue). Lets see, what have I > heard so far? Jordan wants a major generification of the mechanism > (about a 3 man-day's worth of work. At least). Peter and Bernd > are posting their favorite (and apparently extremely complex and > non-standard) partitioning methodologies, neither of which is The *non-standard* is still documented in /usr/share/doc/smm/01.setup/paper.ascii.gz Peters layout isn't that different from that documented and mine. The paper claims different partitions for /usr/src and /usr/obj. Peter, the paper and me agree that they don't belong onto the /usr partition itself. I also softlink them into the right place - usually a network path as I do buildworlds on a single machine for each architecture. What realy belongs into an /usr partition is very static in size: ticso@cicely5# df -k /usr Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0f 183925 132340 36871 78% /usr /usr/local and /usr/X11R6 is network shared so it's impractical to be part of /usr anyway. An 1.5G /usr might be OK for the usual desktop system and if you don't want - well you can always change the size to your needs. But I'm against an /tmp->/var/tmp softlink and I'm against /home because both are non-standard for good reasons. I already explained them in my last mail. If you say /var/home or /var/users and maybe an softlink from /home we can agree for home. That way the realpathname remains in /var, /home can easily replaced with a network volume. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 19:59:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 1F64537B417 for ; Sat, 8 Dec 2001 19:59:36 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB93xTL34741; Sat, 8 Dec 2001 19:59:29 -0800 (PST) (envelope-from dillon) Date: Sat, 8 Dec 2001 19:59:29 -0800 (PST) From: Matthew Dillon Message-Id: <200112090359.fB93xTL34741@apollo.backplane.com> To: Bernd Walter Cc: Peter Wemm , Wilko Bulte , "David O'Brien" , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) References: <20011209003829.C6171@cicely8.cicely.de> <20011209005732.019053808@overcee.netplex.com.au> <20011209025547.B7042@cicely8.cicely.de> <200112090223.fB92NKf34327@apollo.backplane.com> <20011209041249.D7042@cicely8.cicely.de> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG /var/users vs /home is a discussable point, but none of the rest of your posting makes any sense. Network mounts have absolutely nothing whatsoever to do with sysinstall's 'A'uto partitioning option and the paper you site is interesting, but seriously out of date. If I look up /var/users in google (which really treats them as two separate words, but it's still a valid test)... I get 347 hits. Total. If I look up /usr/home I get around 46,500 hits, a quick perursal seems to indicate that this test is reasonably valid. Of course /home won't work in google (you get 232 million results), but in relative terms I would say that it's pretty conclusive that at least in so far as the paper you are siting, very few people have actually partitioned their machines with a /var/users. Not even freefall.freebsd.org uses /var/users. It uses //home (/d/home, etc...)... essentially /home, so I would hardly call my use of /home in sysinstall 'non standard'. If we look at the 'adduser' perl script (/usr/src/usr.sbin/adduser), which I did *NOT* write by the way, it presumes /home as the default. So, again, it would seem that my choice of /home is fairly standard. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 20:13:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id C6C7937B405 for ; Sat, 8 Dec 2001 20:13:40 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id XAA22189; Sat, 8 Dec 2001 23:13:34 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id fB94D9I08632; Sat, 8 Dec 2001 23:13:09 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15378.58581.711516.632169@grasshopper.cs.duke.edu> Date: Sat, 8 Dec 2001 23:13:09 -0500 (EST) To: Matthew Dillon Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: <200112080543.fB85hSt00738@apollo.backplane.com> References: <31807.1007732134@axl.seasidesoftware.co.za> <200112072257.fB7MvjE95211@apollo.backplane.com> <200112072311.fB7NB2723789@whizzo.transsys.com> <200112080349.fB83nWU00292@apollo.backplane.com> <15377.41198.83638.460387@grasshopper.cs.duke.edu> <200112080543.fB85hSt00738@apollo.backplane.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon writes: > :Let's not forget /var/crash. I always make var at least twice as > :large as the physical memory in the box, plus some slop, so I have > :enough room to hold 2 crashdumps. <..> > > That's problematic. /var's size requirements tend to > be fairly static, unrelated to the amount of memory > the machine might have. A machine that doesn't act > as a mail spool or repository generally doesn't need > a large /var. So if you have a machine with 512M of > ram and we create a 1G /var it will almost certainly > remain 99% empty for the entire life of the machine. > > The only time I have ever created a /var larger then > 512M is on mail relays and shell machines with > thousands of users. > > So creating a /var based on available physical ram > is problematic. If your machine has a lot of memory > you will almost certainly be wasting a huge amount > of disk space for a /var that will never get more > then 1% full (except for the occassional crash dump) > It isn't worth it. > > What I do, personally, is cap /var at 512M and if > I have a machine with more memory and I want > crash dumps I softlink /var/crash to either > /usr/var.crash, or /home/var.crash. Or I run > savecore manually to another directory after > boot. Yeah, this is what I do when I have a machine whose disk is tiny. > My recommendation for auto-generating /var is > that we not make it larger then 512M. Then our location of /var/crash appears to be in confict with the purpose of /var, so we should move /var/crash to /usr/crash, or teach "dump" to be smarter & not dump the entire memory of the machine in the first place. Eg, don't dump vnode backed pages, free pages, or portions of the address space which aren't backed by physical memory.. FWIW, Tru64 does this (or something like it, its crashdumps are tiny). Totally off topic, but they optionally do a compressed dump to ram & hand that chunk of memory to savecore on a reboot. Quite slick. I really appreciate your efforts to make the partiton size defaults more sane. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 20:14: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id DC48F37B405 for ; Sat, 8 Dec 2001 20:14:00 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011209041400.PDAO24045.rwcrmhc53.attbi.com@peter3.wemm.org> for ; Sun, 9 Dec 2001 04:14:00 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id fB94E0s28721 for ; Sat, 8 Dec 2001 20:14:00 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 28C423808; Sat, 8 Dec 2001 20:14:00 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Matthew Dillon Cc: Bernd Walter , Wilko Bulte , "David O'Brien" , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: <200112090359.fB93xTL34741@apollo.backplane.com> Date: Sat, 08 Dec 2001 20:14:00 -0800 From: Peter Wemm Message-Id: <20011209041400.28C423808@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: > Not even freefall.freebsd.org uses /var/users. It uses //home > (/d/home, etc...)... essentially /home, so I would hardly call my > use of /home in sysinstall 'non standard'. On freefall, /home is a symlink to /d/home, where everybody's homedir is. > If we look at the 'adduser' perl script (/usr/src/usr.sbin/adduser), > which I did *NOT* write by the way, it presumes /home as the default. > So, again, it would seem that my choice of /home is fairly standard. Yes, Sun essentially set this as a precedent. It is very very widespread. Incidently, I wonder if we're doing this all in the wrong order.. Maybe we should be doing package selections first so that we know what the baseline system space requirements will be. Once we know what is going to be installed, we can make fairly realistic extrapolations about how to size things. Nothing sucks more than having sysinstall bomb out due to lack of space.Maybe we should be doing the partition sizing *last* ? Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 20:15:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ambrisko.com (adsl-64-174-51-42.dsl.snfc21.pacbell.net [64.174.51.42]) by hub.freebsd.org (Postfix) with ESMTP id A77ED37B416 for ; Sat, 8 Dec 2001 20:15:17 -0800 (PST) Received: (from ambrisko@localhost) by ambrisko.com (8.11.6/8.11.6) id fB94Eoa19371; Sat, 8 Dec 2001 20:14:51 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200112090414.fB94Eoa19371@ambrisko.com> Subject: Re: Using a larger block size on large filesystems In-Reply-To: <200112081909.fB8J9TB06131@apollo.backplane.com> To: Matthew Dillon Date: Sat, 8 Dec 2001 20:14:50 -0800 (PST) Cc: freebsd-arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon writes: | :I know you've mentioned this before. Are there technical reasons behind | :this? I believe you mentioned something about the buffer cache? Would | :you be willing to add it as an option since so many others seem to want | :it? | | Most of the stuff that winds up in /tmp is garbage. There is no good | reason to burden our VM system with unnecessary garbage and I know of | no performance issues involved with people using /tmp files that requires | MFS or MD. It's an unnecessary waste of memory and an unnecessary burden | on our VM system. Unless you want a cvs pserver to run fast! I did some benchmarks a while back (port 4.2 I think) in which I had /tmp on soft-updates. It was a little faster on "cvs co freebsd" for example. CVS pserver was running on a dedicated machine and the CVS client was on another. Switched to MFS made a significant improvement. I don't have the number anymore (changed employers). I think the issue here is that CVS on the pserver checks out a sparse tree of the meta data for the each directory that you need. I recall directory operations are sync'd. So creating all the directories and syncing them becomes the gating factor. BTW we ended up sticking a lot of memory in that machine to prevent swaping. We had about 20 people using it. One thing I didn't try was mounting /tmp as async and maybe noatime. That might be an interesting thing to try. Doug A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 20:32: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 269E637B416 for ; Sat, 8 Dec 2001 20:32:04 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011209043154.RHIN5859.rwcrmhc51.attbi.com@peter3.wemm.org> for ; Sun, 9 Dec 2001 04:31:54 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id fB94W3s28793 for ; Sat, 8 Dec 2001 20:32:03 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 889DE3808; Sat, 8 Dec 2001 20:32:03 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Matthew Dillon Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: <200112090223.fB92NKf34327@apollo.backplane.com> Date: Sat, 08 Dec 2001 20:32:03 -0800 From: Peter Wemm Message-Id: <20011209043203.889DE3808@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: .. > Ah well. Perhaps my expectations were a little too high. Sounds like you're discovering the true nature of the freebsd-bikeshed^H^H^H^H^H^H^Harch mailing list. :-) Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 20:58:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 8475337B417 for ; Sat, 8 Dec 2001 20:58:47 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB94wkW35035; Sat, 8 Dec 2001 20:58:46 -0800 (PST) (envelope-from dillon) Date: Sat, 8 Dec 2001 20:58:46 -0800 (PST) From: Matthew Dillon Message-Id: <200112090458.fB94wkW35035@apollo.backplane.com> To: Doug Ambrisko Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems References: <200112090414.fB94Eoa19371@ambrisko.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :| no performance issues involved with people using /tmp files that requires :| MFS or MD. It's an unnecessary waste of memory and an unnecessary burden :| on our VM system. : :Unless you want a cvs pserver to run fast! I did some benchmarks a while :back (port 4.2 I think) in which I had /tmp on soft-updates. It was :a little faster on "cvs co freebsd" for example. CVS pserver was running :on a dedicated machine and the CVS client was on another. Switched to Try it with softupdates turned on. Still, I'd expect MFS to be faster even against softupdates, but that doesn't mean its a good idea to create an MFS /tmp by default. At BEST we wound up putting the sendmail domain cache under MFS for similar reasons, but we never put /tmp under MFS (on any machine)... physical ram was far too precious to waste on /tmp. :MFS made a significant improvement. I don't have the number anymore :(changed employers). I think the issue here is that CVS on the pserver :checks out a sparse tree of the meta data for the each directory :... : :One thing I didn't try was mounting /tmp as async and maybe noatime. :That might be an interesting thing to try. : :Doug A. : -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 21: 4:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 2147237B405 for ; Sat, 8 Dec 2001 21:04:46 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB954jN35081; Sat, 8 Dec 2001 21:04:45 -0800 (PST) (envelope-from dillon) Date: Sat, 8 Dec 2001 21:04:45 -0800 (PST) From: Matthew Dillon Message-Id: <200112090504.fB954jN35081@apollo.backplane.com> To: Peter Wemm Cc: Bernd Walter , Wilko Bulte , "David O'Brien" , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) References: <20011209041400.28C423808@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :Incidently, I wonder if we're doing this all in the wrong order.. Maybe we :should be doing package selections first so that we know what the baseline :system space requirements will be. : :Once we know what is going to be installed, we can make fairly realistic :extrapolations about how to size things. Nothing sucks more than having :sysinstall bomb out due to lack of space.Maybe we should be doing the :partition sizing *last* ? : :Cheers, :-Peter :-- :Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au Well, this only solves part of the problem. What's the very first thing you do after you install FreeBSD from CDRom? The very first thing I do is install a bunch of ports. i.e. package selection at sysinstall-time is not a good indication of what a machine is going to be used for. A minimum indication, certainly... if we can figure out how much space an installed package takes we can check space requirements. If we did the package selection before partitioning the space requirements could be used to set the minimum (NOMINAL in my patch) partition sizes. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 21: 5:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id A246937B405 for ; Sat, 8 Dec 2001 21:05:41 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id fB954vP09490; Sat, 8 Dec 2001 21:04:57 -0800 (PST) (envelope-from obrien) Date: Sat, 8 Dec 2001 21:04:57 -0800 From: "David O'Brien" To: Bernd Walter Cc: Matthew Dillon , Jordan Hubbard , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) Message-ID: <20011208210457.C332@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG Mail-Followup-To: Bernd Walter , Matthew Dillon , Jordan Hubbard , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG References: <49294.1007846108@winston.freebsd.org> <200112082211.fB8MBGm18685@apollo.backplane.com> <20011209013340.D6171@cicely8.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011209013340.D6171@cicely8.cicely.de>; from ticso@cicely8.cicely.de on Sun, Dec 09, 2001 at 01:33:40AM +0100 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Dec 09, 2001 at 01:33:40AM +0100, Bernd Walter wrote: > On Sat, Dec 08, 2001 at 02:11:16PM -0800, Matthew Dillon wrote: > > Hmm. Well, I have to disagree somewhat. 'A'uto isn't useful if > > the user has to think too much about it, and there is nothing > > preventing the user from deleting the partitions he doesn't want. > > /var/tmp and /home are fairly standard partition names... nothing > > new in my book. I certainly didn't invent them! In particular, > > these two partitions greatly increase the safety of the system... I > > can't count the number of times I've seen fsck *fail* on /var/tmp > > after a crash and was thankful that /var/tmp wasn't on /var. > > I hate if Software writes on /var/tmp instead of /tmp. Then rewrite /usr/include/paths.h:#define _PATH_VARTMP "/var/tmp/" /usr/include/stdio.h:#define P_tmpdir "/var/tmp/" the software is just obeying what we told it. > The traditional directory is /var/users but I prefer /var/home. Not for *ages* (if ever). Where have you seen this? > If you don't want a separate /home partition /var/users is the better > choice. > /home is the place for system wide home directories which are usualy > non-local - therefor no need for a local partition. /home has become *The* standard place for one's home dir. Be it local or NFS. Matt is doing the right thing here. If you have an NFS mounted /home, then you can either not use (A)uto, or tweak the result of (A)uto before continuing with the installation. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 21: 8:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id D44A137B405 for ; Sat, 8 Dec 2001 21:08:38 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id fB958JN09516; Sat, 8 Dec 2001 21:08:19 -0800 (PST) (envelope-from obrien) Date: Sat, 8 Dec 2001 21:08:19 -0800 From: "David O'Brien" To: Nate Williams Cc: Matthew Dillon , Jordan Hubbard , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) Message-ID: <20011208210819.D332@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <49294.1007846108@winston.freebsd.org> <200112082211.fB8MBGm18685@apollo.backplane.com> <15378.46543.229258.473566@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15378.46543.229258.473566@caddis.yogotech.com>; from nate@yogotech.com on Sat, Dec 08, 2001 at 05:52:31PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Dec 08, 2001 at 05:52:31PM -0700, Nate Williams wrote: > As David and others have pointed out, they like monstrous '/' partitions > which I shudder to think about when crashes occur. I've never lost my huge / on my main desktop and NFS server. And since I run -CURRENT, I crash or deadlock weekly (since the past year) for one reason or another. Same for my Alpha's with 1.5GB /'s (and you've probably heard me cry how unstable they have been in 2001 also). I agree with you that /var/tmp seems to be too controversial. But there does seem to be some support for a (A)uto /home, in order to allow better sizing of /usr (and reduce the only "default" thing that causes constant writes to /usr). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 21:12: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id AFA4E37B405 for ; Sat, 8 Dec 2001 21:12:06 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id fB95Bgd09596; Sat, 8 Dec 2001 21:11:42 -0800 (PST) (envelope-from obrien) Date: Sat, 8 Dec 2001 21:11:42 -0800 From: "David O'Brien" To: Bernd Walter Cc: Matthew Dillon , Peter Wemm , Wilko Bulte , "David O'Brien" , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) Message-ID: <20011208211142.E332@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20011209003829.C6171@cicely8.cicely.de> <20011209005732.019053808@overcee.netplex.com.au> <20011209025547.B7042@cicely8.cicely.de> <200112090223.fB92NKf34327@apollo.backplane.com> <20011209041249.D7042@cicely8.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011209041249.D7042@cicely8.cicely.de>; from ticso@cicely8.cicely.de on Sun, Dec 09, 2001 at 04:12:49AM +0100 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Dec 09, 2001 at 04:12:49AM +0100, Bernd Walter wrote: > /usr/local and /usr/X11R6 is network shared so it's impractical > to be part of /usr anyway. You've just admitted to (1) not being a typical install, (2) knowing you have suffient clue to not use (A)uto and instead craft the partitions so they work best in your environment. You are *totally* missing the fact that (A)uto is designed for the 1st time, or non-sophisticated user. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 21:25:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id D159137B405 for ; Sat, 8 Dec 2001 21:25:16 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.0/8.11.0) with UUCP id fB95PFG68056; Sun, 9 Dec 2001 06:25:15 +0100 (CET) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id fB95CXtx085965; Sun, 9 Dec 2001 06:12:33 +0100 (CET)?g (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id fB95CXW03061; Sun, 9 Dec 2001 06:12:33 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.6/8.11.6) id fB95CVX07815; Sun, 9 Dec 2001 06:12:32 +0100 (CET) (envelope-from ticso) Date: Sun, 9 Dec 2001 06:12:31 +0100 From: Bernd Walter To: Matthew Dillon Cc: Peter Wemm , Wilko Bulte , "David O'Brien" , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) Message-ID: <20011209061231.E7042@cicely8.cicely.de> References: <20011209003829.C6171@cicely8.cicely.de> <20011209005732.019053808@overcee.netplex.com.au> <20011209025547.B7042@cicely8.cicely.de> <200112090223.fB92NKf34327@apollo.backplane.com> <20011209041249.D7042@cicely8.cicely.de> <200112090359.fB93xTL34741@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200112090359.fB93xTL34741@apollo.backplane.com> User-Agent: Mutt/1.3.23i X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Dec 08, 2001 at 07:59:29PM -0800, Matthew Dillon wrote: > /var/users vs /home is a discussable point, but none of the rest of > your posting makes any sense. Network mounts have absolutely nothing > whatsoever to do with sysinstall's 'A'uto partitioning option and > the paper you site is interesting, but seriously out of date. Sysinstalls job is not to configure network mounts, but it's also not it's job to get in the way which it would in the /home case. > If I look up /var/users in google (which really treats them as two > separate words, but it's still a valid test)... I get 347 hits. Total. > If I look up /usr/home I get around 46,500 hits, a quick perursal seems > to indicate that this test is reasonably valid. Of course /home won't > work in google (you get 232 million results), but in relative terms > I would say that it's pretty conclusive that at least in so far as > the paper you are siting, very few people have actually partitioned > their machines with a /var/users. I also bet you will get more linux and windows hits than freebsd. And you also find hits for /usr/tmp, /usr/mail ... What masses do isn't always an indicator of what is beeing right. Yes - and I have /home too - it's my network shared home. > Not even freefall.freebsd.org uses /var/users. It uses //home > (/d/home, etc...)... essentially /home, so I would hardly call my > use of /home in sysinstall 'non standard'. /home is pointing to a network shared home - right? /var/users is local - if you have a local home. That doesn't mean that you can't link them against if you don't see the need to differenciate. > If we look at the 'adduser' perl script (/usr/src/usr.sbin/adduser), > which I did *NOT* write by the way, it presumes /home as the default. > So, again, it would seem that my choice of /home is fairly standard. This is only a sign that it's already been diffused. As long as you don't have local homes and network wide homes together it doesn't matter - but I doubt that any serious administrator of a multihost user architecture uses adduser. Just an example: You use /home on a single machine and later add another machine. Now you may want a shared home for both machines. But were do you mount it? /var/home? /net/home? You can export your existing /home, but this is already filled with stuff that may only be of local interest. Users may have scripts or even binaries that won't work on the newer machine. There is realy a need for local homedirectories in addition to network shared home directories - either you have security issues not to put every data on the network or people do things that they never need on other machines. I've seen users beginning to create their own local homedirectories in /var/tmp or /tmp just because they needed one. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 21:34:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 8A5D637B423 for ; Sat, 8 Dec 2001 21:34:35 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.0/8.11.0) with UUCP id fB95YYe68087; Sun, 9 Dec 2001 06:34:34 +0100 (CET) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id fB95NHtx085988; Sun, 9 Dec 2001 06:23:17 +0100 (CET)?g (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id fB95NGW03068; Sun, 9 Dec 2001 06:23:16 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.6/8.11.6) id fB95NDC07842; Sun, 9 Dec 2001 06:23:13 +0100 (CET) (envelope-from ticso) Date: Sun, 9 Dec 2001 06:23:13 +0100 From: Bernd Walter To: Peter Wemm Cc: Matthew Dillon , Wilko Bulte , "David O'Brien" , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) Message-ID: <20011209062312.F7042@cicely8.cicely.de> References: <200112090359.fB93xTL34741@apollo.backplane.com> <20011209041400.28C423808@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011209041400.28C423808@overcee.netplex.com.au> User-Agent: Mutt/1.3.23i X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Dec 08, 2001 at 08:14:00PM -0800, Peter Wemm wrote: > Matthew Dillon wrote: > > If we look at the 'adduser' perl script (/usr/src/usr.sbin/adduser), > > which I did *NOT* write by the way, it presumes /home as the default. > > So, again, it would seem that my choice of /home is fairly standard. > > Yes, Sun essentially set this as a precedent. It is very very widespread. I never said anything else - for a network shared home. On Solaris /home defaults beeing an automounted directory - guess why. If you want /home to be a local directory you first have to remove it's connection in /etc/auto_master. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 21:42: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 0B08137B423 for ; Sat, 8 Dec 2001 21:42:01 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB95fuJ35335; Sat, 8 Dec 2001 21:41:56 -0800 (PST) (envelope-from dillon) Date: Sat, 8 Dec 2001 21:41:56 -0800 (PST) From: Matthew Dillon Message-Id: <200112090541.fB95fuJ35335@apollo.backplane.com> To: Bernd Walter Cc: Peter Wemm , Wilko Bulte , "David O'Brien" , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) References: <20011209003829.C6171@cicely8.cicely.de> <20011209005732.019053808@overcee.netplex.com.au> <20011209025547.B7042@cicely8.cicely.de> <200112090223.fB92NKf34327@apollo.backplane.com> <20011209041249.D7042@cicely8.cicely.de> <200112090359.fB93xTL34741@apollo.backplane.com> <20011209061231.E7042@cicely8.cicely.de> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :/home is pointing to a network shared home - right? :/var/users is local - if you have a local home. :That doesn't mean that you can't link them against if you don't see the :need to differenciate. Again, this doesn't make much sense to me. Who says /home has to point to a network share? Who says /var/users has to be local? When people get involved with network configurations there are no standards... there are a thousand ways to set such a machine up. For example, at BEST the /home's on our shell machines containing mainly softlinks, one for each user, pointing to various other partitions. Administrative directories were left in /home, user directories were typically softlinks to other partitions, and on our old SGI's user directories in the /home of one machine were softlinked to NFS mounted volumes. :This is only a sign that it's already been diffused. :As long as you don't have local homes and network wide homes together :it doesn't matter - but I doubt that any serious administrator of a :multihost user architecture uses adduser. And I doubt any serious administrator of a multihost user architecture uses the 'A'uto option to sysinstall either, a point I've tried to make several times that you seem to be missing. :Just an example: :You use /home on a single machine and later add another machine. :Now you may want a shared home for both machines. :But were do you mount it? /var/home? /net/home? There are thousand ways this could be done. You might want to mount the network home on /home. Me? I would probably mount the network home on /machine/home and create softlinks in my local /home to point to it on a user by user basis. Amoung other things that would allow me to distribute my userbase across a number of NFS servers if I so desired, rather then just one, and I could still place administrative directories in the same local /home directly (without a softlink) to ensure that the machine could still be booted into single-user or into multi-user with only administrative accounts active. This type of configuration also allows me to distribute my users across local partitions (e.g. /u1, /u2, /u3) or a combination of local and remote partitons without having to worry about the crash of a 'large' disk taking out a heavily used path like /home. Etc... It is simply not the 'A'uto option's job to try to deal with these complex situations. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 21:43:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 03E9437B416; Sat, 8 Dec 2001 21:43:20 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id WAA12327; Sat, 8 Dec 2001 22:43:08 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id fB95h7X78658; Sat, 8 Dec 2001 22:43:07 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15378.63979.640344.655672@caddis.yogotech.com> Date: Sat, 8 Dec 2001 22:43:07 -0700 To: obrien@FreeBSD.ORG Cc: Nate Williams , Matthew Dillon , Jordan Hubbard , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: <20011208210819.D332@dragon.nuxi.com> References: <49294.1007846108@winston.freebsd.org> <200112082211.fB8MBGm18685@apollo.backplane.com> <15378.46543.229258.473566@caddis.yogotech.com> <20011208210819.D332@dragon.nuxi.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > As David and others have pointed out, they like monstrous '/' partitions > > which I shudder to think about when crashes occur. > > I've never lost my huge / on my main desktop and NFS server. > And since I run -CURRENT, I crash or deadlock weekly (since the past > year) for one reason or another. Same for my Alpha's with 1.5GB /'s (and > you've probably heard me cry how unstable they have been in 2001 also). > > I agree with you that /var/tmp seems to be too controversial. But there > does seem to be some support for a (A)uto /home, in order to allow better > sizing of /usr (and reduce the only "default" thing that causes constant > writes to /usr). My experience is that I'd rather have one humongous writable partition than lots of little partitions. I too often run out of space on the smaller partitions while still having lots of free space on the other partitions that I can't use, so I end up with lots of symlinks and copying of files to free up space as partitions slowly bloat themselves. of little partitions, and now /usr is full because it grew By using one humongous partition I avoid these kind of problems. So, I prefer a big /var vs. a separated out /var and /var/tmp. I prefer a big /usr vs. a smaller /usr and a /home. But, as stated before, this is my personal preference. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 21:55:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 37CDC37B419; Sat, 8 Dec 2001 21:55:14 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id fB95tDQ18827; Sun, 9 Dec 2001 00:55:13 -0500 (EST) (envelope-from wollman) Date: Sun, 9 Dec 2001 00:55:13 -0500 (EST) From: Garrett Wollman Message-Id: <200112090555.fB95tDQ18827@khavrinen.lcs.mit.edu> To: jhb@FreeBSD.ORG Subject: Re: Perl 5.6.1 in the base.... In-Reply-To: References: <20011206162943.A74937@ninja1.internal> Organization: MIT Laboratory for Computer Science Cc: arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [Apologies for getting into this discussion late... I just a few hours ago got back from LISA in San Diego.] >Nope. The perl in -current is 5.6.0. The problem is that the Perl upgrades >are quite hard to do and get right. And the Perl in -stable should stay as it is, unless you want to start erecting a giant banner that reads, ``FreeBSD Project screws -stable users yet again''. Remember, whenever the Perl version changes, every single Perl extension on the system has to be (at best) reinstalled. That's assuming, of course, that you can find them all. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 22:16:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id F214137B405; Sat, 8 Dec 2001 22:16:07 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id 43180786E6; Sun, 9 Dec 2001 16:46:06 +1030 (CST) Date: Sun, 9 Dec 2001 16:46:06 +1030 From: Greg Lehey To: Mike Smith Cc: arch@FreeBSD.ORG, Marko Zec , "Louis A. Mamakos" , Matthew Dillon , Sheldon Hearn , freebsd-arch@FreeBSD.ORG Subject: Getting rid of /usr file system (was: Using a larger block size on large filesystems) Message-ID: <20011209164606.C83634@monorchid.lemis.com> References: <20011208102658.B11428@dragon.nuxi.com> <200112082050.fB8Ko1T01347@mass.dis.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: <200112082050.fB8Ko1T01347@mass.dis.org> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Saturday, 8 December 2001 at 12:50:01 -0800, Mike Smith wrote: >>> Why would we want to do that? Putting unnecessary things on / is always a >>> bad idea, as root partition should remain small and as free of frequent RW >>> operations as possible. >> >> That is a *PERSONAL* opinion, so please mark it as such. I personally >> use 1.5GB / partitions. I _personally_ see zero reason for a /usr >> partition. > > PERSONALLY, I disagree. 1.5GB is too small these days; 2GB is a better > choice. 8) Well, since we're all being personal, here's my opinion. Yes, I agree with David that /usr has outlived its use-by date. It was originally developed because the root file system at the time went on a 512 kB disk, and it needed to be separate. It was kept for a long time because of superstition that it might help recover file systems badly broken as the result of a crash. In fact, it does pretty much the opposite: it means that a lot of tools are not available in single user mode unless you mount /usr, since the dynamic libraries are on /usr. It doesn't pose much of a crash or corruption danger, since it's hardly ever written to nowadays. And of course, it's not /usr at all any more, it's /system. I've been running systems like this for a few years. I disagree with both of you about size; 4 GB is the one true size. You can fit it on a DDS-2 tape, and it's big enough to keep /usr/local on the same file system. I've tried with 2 GB, and that's definitely too small. 3 GB might be OK, but in a few years' time that will be too small too. You can discount this all you want, but if you have good, solid arguments against doing it, speak now: otherwise this recommendation with be in the next edition (soon!) of "The Complete FreeBSD". I'm attaching an extract from the current draft; criticize all you want. > Then again, I work for a company that puts everything in > /System/Library, so I guess I should be quiet now. 8) Sounds ugly, but when you think of it, it makes a fair amount of sense. Greg -- See complete headers for address and phone numbers --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=sizing What size partitions? _____________________ In our example, we have 20 GB of space to divide up. How should we do it? You don't have to worry about this issue, since sysinstall will do it for you if you ask it, but we'll see below why this might not be the best choice. In this section we'll consider how UNIX file systems have changed over the years, and Page 90 install.mm,v v3.5 (2000/08/30 00:08:01) (modified 25 Mar, 2001 UTC) Chapter 6: Installing FreeBSD we'll look at the issues in file system layout nowadays. When UNIX was young, disks were tiny. By the time of the Third Edition of UNIX, in 1972, the root file system was on a Digital RF-11, a fixed head disk with 512 kB. It was no longer possible to keep the entire system on this disk, so a second file system became essential. It was mounted on a Digital RK03 with 2 MB of storage. To quote from a paper published in the Communications of the ACM in July 1974: In our installation, for example, the root directory resides on the fixed-head disk, and the large disk drive, which contains user's files, is mounted by the system initialization program... As time went on, UNIX got bigger, but so did the disks. By the early 80s, disks were large enough to put / and /usr on the same disk, and it would have been possible to merge / and /usr, but they didn't. Since that time, an additional file system, /var, has come into common use for frequently changed data. This is what sysinstall does by default: [Omitting PostScript image images/disk-label-default.ps 4i ] Figure 6-12: Default disk partition sizes It's relatively simple to estimate the size of the root file system, and sysinstall's value of 50 MB is fine. But what about /var? 20 MB isn't worth the trouble any more. In fact, both file systems put together would be lost in the 19 GB of /usr file system. Why do we still do things this way? Let's look at the advantages and disadvantages: o If you write to a file system, a system crash can have serious consequences for the data integrity of that file system. o If you have a crash and lose the root file system, recovery can be difficult. o If a file system fills up, it can cause lots of trouble. Most messages about file systems on the FreeBSD-questions mailing list are complaining about file systems filling up. If you have a large number of small file systems, the chances are higher that one will fill up while space remains on another. o In single-user mode, only the root file system is mounted. With the classical layout, this means that the only programs you can run are those in /bin and /sbin. In order to run any other programs, you must first mount the file system on which they are located. install.mm,v v3.5 (2000/08/30 00:08:01) (modified 25 Mar, 2001 UTC) Page 91 Creating space on disk o It's nice to keep your personal files separate from the system files. That way you can upgrade a system much more easily. o It's very difficult to calculate the sizes of some file systems. For example, on some systems /var can be very small, maybe only 2 or 3 MB. It's hardly worth making a separate file system for that much data. On the other hand, other systems, such as ftp or web servers, may have a /var system of 50 or 100 GB. How do you choose the correct size for your system? o When doing backups, it's a good idea to be able to get a file system on a single tape. In the early days of UNIX, system crashes were relatively common, and the damage they did to the file systems was relatively serious. Times have changed, and nowadays file system damage is relatively seldom, particularly on file systems that have little activity. On the other hand, disk drives have grown beyond most peoples' wildest expectations. The first edition of this book, only five years ago, showed how to install on a 200 MB drive. The smallest disk drives in current production are 10 GB in size, more than will fit on many tapes. As a result of these considerations, I have changed my recommendations. In earlier editions of this book, I recommended to put a small root file system and a /usr file system on the first (or only) disk on the system. /var was to be a symbolic link to /usr/var. This is still a valid layout, but it has a couple of problems: o In the example we're looking at, /usr is about 19 GB in size. Not many people have backup devices which can write this much data on a single medium. o Many people had difficulty with the symbolic link to /usr/var. As a result, I now recommend: o Make a single root file system of between 2 and 4 GB. o Do not have separate /usr or /var file systems. o Use the rest of the space on disk for a /home file system, as long as it's possible to back it up on a single tape. Otherwise make multiple file systems. /home is the normal directory for user files. This layout allows for easy backup of the file systems, and it also allows for Page 92 install.mm,v v3.5 (2000/08/30 00:08:01) (modified 25 Mar, 2001 UTC) Chapter 6: Installing FreeBSD easy upgrading to a new system version: you just need to replace the root file system. It's not perfect, though: on a web server you probably wouldn't want to put /var on the root file system. How much swap space? ____________________ Apart from files, you should also have at least one swap partition on your disk. It's very difficult to predict how much swap space you need. The automatic option gave us 522 MB, slightly more than twice the size of physical memory. Maybe you can get by with 64 MB. Maybe you'll need 2 GB. How do you decide? It's almost impossible to know in advance what your system will require. Here are some considerations: o Swap space is needed for all pages of virtual memory which contain data that is not locked in memory and which can't be recreated automatically. This is the majority of virtual memory in the system. o Some people use rules of thumb like ``2.5 times the size of physical memory, or 64 MB, whichever is bigger''. These rules work only by making assumptions about your workload. If you're using more than 2.5 times as much swap space as physical memory, performance will suffer. o Known memory hogs are X11 and integrated graphical programs such as NetScape and StarOffice. If you use these, you will probably need more swap space. Older UNIX-based hogs such as Emacs and the GNU C compiler (gcc) are not in the same league. o You can add additional swap partitions on other disks. This has the additional advantage of balancing the disk load if your machine swaps a lot. o About the only ways to change the size of a swap partition are to add another partition or to reinstall the system, so if you're not sure, a little bit more won't do any harm, but too little can really be a problem. o If your system panics, and memory dumping is enabled, it will write the contents of memory to the swap partition. This will obviously not work if your swap partition is smaller than main memory. Under these circumstances, the system refuses to dump, but it's not impossible that a bug might cause the dump to write beyond the bounds of the swap partition, probably causing irreperable damage to your /usr partition. install.mm,v v3.5 (2000/08/30 00:08:01) (modified 25 Mar, 2001 UTC) Page 93 Creating space on disk o Even with light memory loads, the virtual memory system slowly pages out data in preparation for a possible sudden demand for memory. This means that it can be more responsive to such requests. As a result, you should have at least as much swap as memory. A couple of examples might make this clearer: 1. I used to run X, StarOffice, Netscape and a whole lot of other memory-hungry applications on an old 486 with 16 MB. Sure, it's really slow, especially when changing from one application to another, but it works. Since there's not much memory, it uses a lot of swap. To view the current swap usage, use pstat. Here's a typical view of this machine's swap space: $ pstat -s Device 1024-blocks Used Avail Capacity Type /dev/da0s1b 122880 65148 57668 53% Interleaved 2. I now run much more stuff on an AMD Athlon with 256 MB of memory. I've got lots of swap space, but what I see is: $ pstat -s Device 1024-blocks Used Avail Capacity Type /dev/ad0s1b 524020 22328 501692 4% Interleaved It's not so important that the Athlon is using less swap: it's using 9% of its memory in swap, whereas the 486 is using 4 times its memory. In a previous edition of this book, I had the example of a Pentium with 96 MB of memory, which used 43 MB of swap. Look at it from a different point, and it makes more sense: swap makes up for the lack of real memory, so the 486 is using a total of 80 MB of memory, the Pentium is using 140 MB, and the Athlon is using 280 MB. In other words, there is a tendency to be able to say ``the more main memory you have, the less swap you need''. If, however, you look at it from the point of view of acceptable performance, you will hear things like ``you need at least one-third of your virtual memory in real memory''. That makes sense from a performance point of view, assuming all processes are relatively active. And, of course, it's another way of saying ``take twice as much swap as real memory''. In summary: be generous in allocating swap space. In this example, we have a Page 94 install.mm,v v3.5 (2000/08/30 00:08:01) (modified 25 Mar, 2001 UTC) Chapter 6: Installing FreeBSD tiny disk, so we're forced to use a small swap partition. If you have the choice, use more. If you really can't make up your mind, take 512 MB of swap space. For the file systems, the column Mount now shows the mount points, and Newfs contains the letters UFS for UNIX File System, and the letter Y, indicating that we need to create a new file system before we can use it. At this point, we have two choices: decide for ourselves what we want, or let the disk label editor do it for us. Let's look at both ways: --nFreZHaLTZJo0R7j-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 22:16:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id F214137B405; Sat, 8 Dec 2001 22:16:07 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id 43180786E6; Sun, 9 Dec 2001 16:46:06 +1030 (CST) Date: Sun, 9 Dec 2001 16:46:06 +1030 From: Greg Lehey To: Mike Smith Cc: arch@FreeBSD.ORG, Marko Zec , "Louis A. Mamakos" , Matthew Dillon , Sheldon Hearn , freebsd-arch@FreeBSD.ORG Subject: Getting rid of /usr file system (was: Using a larger block size on large filesystems) Message-ID: <20011209164606.C83634@monorchid.lemis.com> References: <20011208102658.B11428@dragon.nuxi.com> <200112082050.fB8Ko1T01347@mass.dis.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: <200112082050.fB8Ko1T01347@mass.dis.org> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Saturday, 8 December 2001 at 12:50:01 -0800, Mike Smith wrote: >>> Why would we want to do that? Putting unnecessary things on / is always a >>> bad idea, as root partition should remain small and as free of frequent RW >>> operations as possible. >> >> That is a *PERSONAL* opinion, so please mark it as such. I personally >> use 1.5GB / partitions. I _personally_ see zero reason for a /usr >> partition. > > PERSONALLY, I disagree. 1.5GB is too small these days; 2GB is a better > choice. 8) Well, since we're all being personal, here's my opinion. Yes, I agree with David that /usr has outlived its use-by date. It was originally developed because the root file system at the time went on a 512 kB disk, and it needed to be separate. It was kept for a long time because of superstition that it might help recover file systems badly broken as the result of a crash. In fact, it does pretty much the opposite: it means that a lot of tools are not available in single user mode unless you mount /usr, since the dynamic libraries are on /usr. It doesn't pose much of a crash or corruption danger, since it's hardly ever written to nowadays. And of course, it's not /usr at all any more, it's /system. I've been running systems like this for a few years. I disagree with both of you about size; 4 GB is the one true size. You can fit it on a DDS-2 tape, and it's big enough to keep /usr/local on the same file system. I've tried with 2 GB, and that's definitely too small. 3 GB might be OK, but in a few years' time that will be too small too. You can discount this all you want, but if you have good, solid arguments against doing it, speak now: otherwise this recommendation with be in the next edition (soon!) of "The Complete FreeBSD". I'm attaching an extract from the current draft; criticize all you want. > Then again, I work for a company that puts everything in > /System/Library, so I guess I should be quiet now. 8) Sounds ugly, but when you think of it, it makes a fair amount of sense. Greg -- See complete headers for address and phone numbers --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=sizing What size partitions? _____________________ In our example, we have 20 GB of space to divide up. How should we do it? You don't have to worry about this issue, since sysinstall will do it for you if you ask it, but we'll see below why this might not be the best choice. In this section we'll consider how UNIX file systems have changed over the years, and Page 90 install.mm,v v3.5 (2000/08/30 00:08:01) (modified 25 Mar, 2001 UTC) Chapter 6: Installing FreeBSD we'll look at the issues in file system layout nowadays. When UNIX was young, disks were tiny. By the time of the Third Edition of UNIX, in 1972, the root file system was on a Digital RF-11, a fixed head disk with 512 kB. It was no longer possible to keep the entire system on this disk, so a second file system became essential. It was mounted on a Digital RK03 with 2 MB of storage. To quote from a paper published in the Communications of the ACM in July 1974: In our installation, for example, the root directory resides on the fixed-head disk, and the large disk drive, which contains user's files, is mounted by the system initialization program... As time went on, UNIX got bigger, but so did the disks. By the early 80s, disks were large enough to put / and /usr on the same disk, and it would have been possible to merge / and /usr, but they didn't. Since that time, an additional file system, /var, has come into common use for frequently changed data. This is what sysinstall does by default: [Omitting PostScript image images/disk-label-default.ps 4i ] Figure 6-12: Default disk partition sizes It's relatively simple to estimate the size of the root file system, and sysinstall's value of 50 MB is fine. But what about /var? 20 MB isn't worth the trouble any more. In fact, both file systems put together would be lost in the 19 GB of /usr file system. Why do we still do things this way? Let's look at the advantages and disadvantages: o If you write to a file system, a system crash can have serious consequences for the data integrity of that file system. o If you have a crash and lose the root file system, recovery can be difficult. o If a file system fills up, it can cause lots of trouble. Most messages about file systems on the FreeBSD-questions mailing list are complaining about file systems filling up. If you have a large number of small file systems, the chances are higher that one will fill up while space remains on another. o In single-user mode, only the root file system is mounted. With the classical layout, this means that the only programs you can run are those in /bin and /sbin. In order to run any other programs, you must first mount the file system on which they are located. install.mm,v v3.5 (2000/08/30 00:08:01) (modified 25 Mar, 2001 UTC) Page 91 Creating space on disk o It's nice to keep your personal files separate from the system files. That way you can upgrade a system much more easily. o It's very difficult to calculate the sizes of some file systems. For example, on some systems /var can be very small, maybe only 2 or 3 MB. It's hardly worth making a separate file system for that much data. On the other hand, other systems, such as ftp or web servers, may have a /var system of 50 or 100 GB. How do you choose the correct size for your system? o When doing backups, it's a good idea to be able to get a file system on a single tape. In the early days of UNIX, system crashes were relatively common, and the damage they did to the file systems was relatively serious. Times have changed, and nowadays file system damage is relatively seldom, particularly on file systems that have little activity. On the other hand, disk drives have grown beyond most peoples' wildest expectations. The first edition of this book, only five years ago, showed how to install on a 200 MB drive. The smallest disk drives in current production are 10 GB in size, more than will fit on many tapes. As a result of these considerations, I have changed my recommendations. In earlier editions of this book, I recommended to put a small root file system and a /usr file system on the first (or only) disk on the system. /var was to be a symbolic link to /usr/var. This is still a valid layout, but it has a couple of problems: o In the example we're looking at, /usr is about 19 GB in size. Not many people have backup devices which can write this much data on a single medium. o Many people had difficulty with the symbolic link to /usr/var. As a result, I now recommend: o Make a single root file system of between 2 and 4 GB. o Do not have separate /usr or /var file systems. o Use the rest of the space on disk for a /home file system, as long as it's possible to back it up on a single tape. Otherwise make multiple file systems. /home is the normal directory for user files. This layout allows for easy backup of the file systems, and it also allows for Page 92 install.mm,v v3.5 (2000/08/30 00:08:01) (modified 25 Mar, 2001 UTC) Chapter 6: Installing FreeBSD easy upgrading to a new system version: you just need to replace the root file system. It's not perfect, though: on a web server you probably wouldn't want to put /var on the root file system. How much swap space? ____________________ Apart from files, you should also have at least one swap partition on your disk. It's very difficult to predict how much swap space you need. The automatic option gave us 522 MB, slightly more than twice the size of physical memory. Maybe you can get by with 64 MB. Maybe you'll need 2 GB. How do you decide? It's almost impossible to know in advance what your system will require. Here are some considerations: o Swap space is needed for all pages of virtual memory which contain data that is not locked in memory and which can't be recreated automatically. This is the majority of virtual memory in the system. o Some people use rules of thumb like ``2.5 times the size of physical memory, or 64 MB, whichever is bigger''. These rules work only by making assumptions about your workload. If you're using more than 2.5 times as much swap space as physical memory, performance will suffer. o Known memory hogs are X11 and integrated graphical programs such as NetScape and StarOffice. If you use these, you will probably need more swap space. Older UNIX-based hogs such as Emacs and the GNU C compiler (gcc) are not in the same league. o You can add additional swap partitions on other disks. This has the additional advantage of balancing the disk load if your machine swaps a lot. o About the only ways to change the size of a swap partition are to add another partition or to reinstall the system, so if you're not sure, a little bit more won't do any harm, but too little can really be a problem. o If your system panics, and memory dumping is enabled, it will write the contents of memory to the swap partition. This will obviously not work if your swap partition is smaller than main memory. Under these circumstances, the system refuses to dump, but it's not impossible that a bug might cause the dump to write beyond the bounds of the swap partition, probably causing irreperable damage to your /usr partition. install.mm,v v3.5 (2000/08/30 00:08:01) (modified 25 Mar, 2001 UTC) Page 93 Creating space on disk o Even with light memory loads, the virtual memory system slowly pages out data in preparation for a possible sudden demand for memory. This means that it can be more responsive to such requests. As a result, you should have at least as much swap as memory. A couple of examples might make this clearer: 1. I used to run X, StarOffice, Netscape and a whole lot of other memory-hungry applications on an old 486 with 16 MB. Sure, it's really slow, especially when changing from one application to another, but it works. Since there's not much memory, it uses a lot of swap. To view the current swap usage, use pstat. Here's a typical view of this machine's swap space: $ pstat -s Device 1024-blocks Used Avail Capacity Type /dev/da0s1b 122880 65148 57668 53% Interleaved 2. I now run much more stuff on an AMD Athlon with 256 MB of memory. I've got lots of swap space, but what I see is: $ pstat -s Device 1024-blocks Used Avail Capacity Type /dev/ad0s1b 524020 22328 501692 4% Interleaved It's not so important that the Athlon is using less swap: it's using 9% of its memory in swap, whereas the 486 is using 4 times its memory. In a previous edition of this book, I had the example of a Pentium with 96 MB of memory, which used 43 MB of swap. Look at it from a different point, and it makes more sense: swap makes up for the lack of real memory, so the 486 is using a total of 80 MB of memory, the Pentium is using 140 MB, and the Athlon is using 280 MB. In other words, there is a tendency to be able to say ``the more main memory you have, the less swap you need''. If, however, you look at it from the point of view of acceptable performance, you will hear things like ``you need at least one-third of your virtual memory in real memory''. That makes sense from a performance point of view, assuming all processes are relatively active. And, of course, it's another way of saying ``take twice as much swap as real memory''. In summary: be generous in allocating swap space. In this example, we have a Page 94 install.mm,v v3.5 (2000/08/30 00:08:01) (modified 25 Mar, 2001 UTC) Chapter 6: Installing FreeBSD tiny disk, so we're forced to use a small swap partition. If you have the choice, use more. If you really can't make up your mind, take 512 MB of swap space. For the file systems, the column Mount now shows the mount points, and Newfs contains the letters UFS for UNIX File System, and the letter Y, indicating that we need to create a new file system before we can use it. At this point, we have two choices: decide for ourselves what we want, or let the disk label editor do it for us. Let's look at both ways: --nFreZHaLTZJo0R7j-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 22:27:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id E2CA537B41D for ; Sat, 8 Dec 2001 22:27:27 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id B6CCD786E6; Sun, 9 Dec 2001 16:57:25 +1030 (CST) Date: Sun, 9 Dec 2001 16:57:25 +1030 From: Greg Lehey To: Matthew Dillon Cc: Jordan Hubbard , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) Message-ID: <20011209165725.D83634@monorchid.lemis.com> References: <49294.1007846108@winston.freebsd.org> <200112082211.fB8MBGm18685@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200112082211.fB8MBGm18685@apollo.backplane.com> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Saturday, 8 December 2001 at 14:11:16 -0800, Matthew Dillon wrote: > Hmm. Well, I have to disagree somewhat. 'A'uto isn't useful if > the user has to think too much about it, and there is nothing > preventing the user from deleting the partitions he doesn't want. > /var/tmp and /home are fairly standard partition names... nothing > new in my book. I certainly didn't invent them! In particular, > these two partitions greatly increase the safety of the system... I > can't count the number of times I've seen fsck *fail* on /var/tmp > after a crash and was thankful that /var/tmp wasn't on /var. Auto isn't much use if it makes the wrong decision. I can't really see how it can make the right decision, given the various usages you can have. > Not only that, but blowing-out /var/tmp is relatively easy to do even > on a single user system. The last thing you want to see is a full > /var/tmp causing your mail system to throw up rocks because it's on > the same partition as /var. There is absolutely no sane reason to > combine /var and /var/tmp together. > > The same thing goes for /home, though in /home's case the reasoning > is somewhat more ephermal. You get the same safety factor in regards > to having a greater chance of recovering /usr after a crash if /home > isn't sitting in /usr (/usr/home) (or sitting in root for that matter!). > (remember why /var was separated from /usr in the first place?). > But you also have the added benefit of making /usr a managed space, > limited to X amount (e.g. 3GB) and placing the remainder of your free > space in /home. It makes far less sense to place the remainder of > your free space in /usr. > > This setup works equally well as a default for both single and > multi-user systems and also works fairly well for power-user > and developer systems, and for most special-purpose systems > except large special-purpose mail spools and repositories (which > typically need a huge /var). It works far better as a default > then simply creating /, /usr, and /var. > > In that light perhaps what we need to do is have an auto-resizing > feature, so if the user deletes an auto-created partition sysinstall > automatically resizes the auto-created partitions before it to fill > up the space. So if the user hits 'A' and doesn't want /var/tmp, they > simply delete /var/tmp and /var gets its space. And if they don't > want /home they simply delete it and /usr gets its space. I think > this is a much easier mechanism for the user then requiring him to > select which Auto-profile to use. > > So despite your objections I am still leaning very heavily towards > wanting to include /var/tmp and /home as defaults for the Auto option. It's clear that you and I have very different opinions on partitioning. I'm not trying to convince you, but it seems to me that for exactly that reason, the user should hear the arguments (yours, mine or somebody else's) and make up his own mind. sysinstall can give him the choice. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 8 22:32:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id E656537B405 for ; Sat, 8 Dec 2001 22:32:22 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id 035E1786E7; Sun, 9 Dec 2001 17:02:20 +1030 (CST) Date: Sun, 9 Dec 2001 17:02:20 +1030 From: Greg Lehey To: Bernd Walter Cc: Matthew Dillon , Jordan Hubbard , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) Message-ID: <20011209170220.E83634@monorchid.lemis.com> References: <49294.1007846108@winston.freebsd.org> <200112082211.fB8MBGm18685@apollo.backplane.com> <20011209013340.D6171@cicely8.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011209013340.D6171@cicely8.cicely.de> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sunday, 9 December 2001 at 1:33:40 +0100, Bernd Walter wrote: > On Sat, Dec 08, 2001 at 02:11:16PM -0800, Matthew Dillon wrote: >> Not only that, but blowing-out /var/tmp is relatively easy to do even >> on a single user system. The last thing you want to see is a full > > Not surprising with a softlink from /tmp to /var/tmp. It would surprise me if the symlink would be the problem. Typically /tmp is much smaller than /var/tmp. >> The same thing goes for /home, though in /home's case the >> reasoning is somewhat more ephermal. You get the same safety >> factor in regards to having a greater chance of recovering /usr >> after a crash if /home isn't sitting in /usr (/usr/home) (or >> sitting in root for that matter!). > > The traditional directory is /var/users but I prefer /var/home. The traditional directory is /usr. /var and /home came at the same time with System V.4 IIRC. I thought we were at least agreed that /home would be the correct name. > If you don't want a separate /home partition /var/users is the > better choice. /home is the place for system wide home directories > which are usualy non-local - therefor no need for a local partition. You can use it like that. It wasn't the original idea. One way or another, it makes sense to separate /usr (system files, including /usr/local) from /home (user files). That way you can upgrade just by replacing /usr. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message