Date: Mon, 21 Jun 1999 17:29:28 +1000 From: Bruce Evans <bde@zeta.org.au> To: attila@hun.org, bde@zeta.org.au Cc: freebsd-current@freeBSD.org Subject: Re: ROOTDEVNAME error in conf/LINT Message-ID: <199906210729.RAA08733@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>*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.... That's not what I see here. LINT uses the backslashes, and the part of it that uses ROODEVNAME has been building properly for several months. >*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 Nothing so complicated. Use slices for everything so you don't have any evil nested partitions :->. > you say there is no arbitrary limit on slices? but... > > <sys/diskslice.h>: #define MAX_SLICES 32 That's not as fundamental as the MAXPARTITIONS limit. Labels really want to live in a single sector. > 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? The slice/label data is outside of FFS. Slice (M$ partition) data is distributed as a linked list but label data is packed into an array. Each of these layouts has advantages and disadvantages. Linked lists are easier to expand and harder to translate. > 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? The openmask bitmaps use type u_char, so MAXPARTITIONS must be <= 8 (== 8 is a bit strong). Larger openmask bitmaps would waste space and not remove the need for the bomb - you would still have to check that MAXPARTITIONS <= NUMBER_OF_BITS_IN_OPENMASK_BITMAP_T. > 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>] No. Slice and partition data is mostly outside of FFS. I implemented slices in a layered fashion mainly so that disklabel and newfs, etc. don't need to know about their internals. > 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. I think lots of small partitions would cause even more latency unless most of them aren't used most of the time. newfs already uses the weired default geometry of 1 track with 4096 sectors partly to handle yesterday's "obscenely" large disks (4GB...). Bruce 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?199906210729.RAA08733>