From owner-freebsd-current Sun Jun 20 23:24:47 1999 Delivered-To: freebsd-current@freebsd.org Received: from hun.org (hun.org [216.190.28.252]) by hub.freebsd.org (Postfix) with ESMTP id 774B714C13 for ; Sun, 20 Jun 1999 23:24:42 -0700 (PDT) (envelope-from attila@hun.org) Received: (from attila@localhost) by hun.org (8.9.3/8.9.2) id GAA11007; Mon, 21 Jun 1999 06:17:09 GMT (envelope-from attila) Date: Mon, 21 Jun 1999 06:17:09 GMT Message-Id: <199906210617.GAA11007@hun.org> From: attila! Reply-To: attila@hun.org To: Bruce Evans Cc: freebsd-current@freeBSD.org Subject: Re: ROOTDEVNAME error in conf/LINT Owner: attila@hun.org Organization: hun.org, over 40 years beyond the fringe home for unpenitent hackers and anarcho-cryptophreaks Mailer: XEmacs V20.4 (see alt.religion.emacs) Encrypted: NO Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 21 Jun 1999, Bruce Evans wrote: *Date: Mon, 21 Jun 1999 09:15:25 +1000 *From: Bruce Evans *To: attila@hun.org, freebsd-current@FreeBSD.ORG *Subject: Re: ROOTDEVNAME error in conf/LINT * *> in /usr/src/sys/i386/conf/LINT *> *>options ROOTDEVNAME=\"da0s2e\" *> *> must be specified as: *> *>options ROOTDEVNAME="da0s2e" *> *> else 'make depend' loses the string. w/o quotes it's just an *> undefined. parser change to eliminate quote requirements *> for config file defines obviated need for hard quotes in *> ROOTDEVNAME>. "config" does not grok the errors. * *No. At least in -current, the former works, but latter gives no quotes *in opt_rootdevname.h and thus a syntax error in autoconf.c. * not so... former does does not work in -current as of current build from cvs files through Thu 17 Jun 99 0616 GMT. the back-slashes hose config. the quotes w/o the literal are parsed correctly in last 48 hours.... *> am one of those who suffers from lack of politically correct *> attitude -- I dont do M$lop (refuse to), so why should I *> worry about slices? never need slices before M$lop.... however, *> that may change as SCSI disk sizes keep climbing and too large *> partitions take performance hits. *> *> alternative is to change MAXPARTITIONS? to 16? * *One reason is that the slice data format is better. It doesn't have *arbitrary limits like 8 or 16 (it's essentially a linked list). * are you suggesting a layout for a disk pair such as: --------------- disk 0 da0s1a 100M root da0s1b 250M swap da0s2c 1G /usr da0s3c 1G /usr/src da0s4c 2G /user da0s5c 1G /usr/local/etc/www/data --------------- disk 1 da1s1e 100 M /tmp da1s1b 250 swap da1s2c 1G /usr/X11R6 da1s3c 4G /usr/prod da1s4c 1G /var you say there is no arbitrary limit on slices? but... : #define MAX_SLICES 32 is the data format better? if so, why? using a slice as a partition does not change the organization of the real estate under FFS if the slice then contains a single "partition" --is it easier to translate slice-partition than it is to translate cylinder-sector information for multiple partitions on a non-sliced disk? OTOH, if you muck with the partition limit, in you run into a wall: #ifdef MAXPARTITIONS /* XXX don't depend on disklabel.h */ #if MAXPARTITIONS != 8 /* but check consistency if possible */ #error "inconsistent MAXPARTITIONS" #endif #else #define MAXPARTITIONS 8 #endif and it will need to be patched as it flat overrides changing MAXPARTITIONS in this raises a flag... why the bomb? or was there a major change in FFS with the advent of the slice? [I'll admit to not _seriously_ looking at the FFS partition code since the early 80s... ] the only reason that merits discussion is the "obscene" sizes of the current generation disks -- 25 Gbyte... 30 Gbyte, etc. if you start defining partitions at 8 Gbyte, you have a large number of cylinders-sectors in the current mapping, which also means a larger number of spare tables to be maintained --all of which probably translates into more accessing latency if you are not doing softupdates which is an idea I am not comfortable with. the problem is that the disks will get larger and larger and the disk version of Parkinson's Law will obviously follow. I can remember going into ecstasy when I took shipment of two 680 Mbyte Fujitsu 10" platter Eagles --one for each VAX... cost me about $12,500 each plus $2,000 for the controller. of course, the VAX750 core box was $38,000 OEM at that time... the point is, we lived with no storage; today, I can not live with 9 Gbyte on the desktop... and a 9Gbyte SCSI drive is <$500. and, to really show my antiquity --IBM 30 gal "pony" magnetic drums... or "walking" the washing machine RP4s... one obvious maneuver might be to increase the absolute sector size from the industry standard of 512 --this requires cooperation from the hardware vendors. yeah, sure...! we can fake it, and do, but with less success. attila out... ___ ___ ___ _ __ ___ | _ ) __| \ freeBSD: The Power to Serve! _ __ ___ ____ | _ \__ \ |) | Release 4.0 - The Fast Lane! _ __ ___ ____ _____ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message