From owner-freebsd-stable Fri Nov 7 19:30:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA13285 for stable-outgoing; Fri, 7 Nov 1997 19:30:43 -0800 (PST) (envelope-from owner-freebsd-stable) Received: from tok.qiv.com (+7dMLPc7CkI8WzyTM54F7zVG+WnTaSTD@[204.214.141.211]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA13280 for ; Fri, 7 Nov 1997 19:30:40 -0800 (PST) (envelope-from jdn@qiv.com) Received: (from uucp@localhost) by tok.qiv.com (8.8.6/8.8.5) with UUCP id VAA16905; Fri, 7 Nov 1997 21:30:26 -0600 (CST) Received: from localhost (jdn@localhost) by acp.qiv.com (8.8.7/8.8.5) with SMTP id VAA01221; Fri, 7 Nov 1997 21:21:01 -0600 (CST) X-Authentication-Warning: acp.qiv.com: jdn owned process doing -bs Date: Fri, 7 Nov 1997 21:21:01 -0600 (CST) From: Jay Nelson To: "Matthew D. Fuller" cc: Satoshi Asami , richard@pegasus.com, stable@FreeBSD.ORG Subject: Re: Partitioning In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 7 Nov 1997, Matthew D. Fuller wrote: [snip] > > What do you mean? ccd is not a filesystem. > I know. > What I meant was, it looks to me like, the code for expanding filesystems > would seem to be a lot like the code for implementing ccd'd partitions; > you just map various physical places on the disk(s) to the same logical > partition. [snip] AIX maps 4Mb physical "partitions" to logical partitions. Physical partitions scattered all over the disk are mapped to a linear logical sequence of partitions. So, in a sense, it probably isn't that much different than ccd. But I'm not that enthusiastic about LVM. As near as I can tell, AIX implements the basic Berkeley filesystem and has completed the journaling. When you expand a file system, I don't believe you gain any more inodes. AIX also uses a number of other structures that are unique -- Volume Descriptor Blocks, for example, which keep track of quorums (for mirroring and "volume groups") and other data related to the current state of the file system. All of this "convenience" implies overhead -- or a massive overhaul of the current file system code. You also have to realize that to make this work, you have to leave portions of the disk(s) unallocated. You could probably simulate this by allocating calendars 0-99, 200-299, etc., and then relabeling the disk when you want to expand. Seems like a waste of space to me given the FFS allocation policies. IMHO, I wouldn't want to invest 1+ man years to implement a convenience to save a 2 or 3 time a year annoyance. (I'd also hate to see FreeBSD broken while it's implemented.) 2000+ hours to implement vs. 2-8 hour backup/rebuild/restore -- plus (gurus correct me if I'm wrong) it takes 4-8 cycles to dereference a pointer -- so you're coming close to doubling file acces time. The dog don't hunt. -- Jay