Date: Mon, 21 Jun 1999 06:17:09 GMT From: attila! <attila@hun.org> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-current@freeBSD.org Subject: Re: ROOTDEVNAME error in conf/LINT Message-ID: <199906210617.GAA11007@hun.org>
next in thread | raw e-mail | index | archive | help
On Mon, 21 Jun 1999, Bruce Evans wrote:
*Date: Mon, 21 Jun 1999 09:15:25 +1000
*From: Bruce Evans <bde@zeta.org.au>
*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...
<sys/diskslice.h>: #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 <sys/diskslice.h>
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 <sys/disklabel.h> 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... <g>]
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906210617.GAA11007>