Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 7 Nov 1997 21:21:01 -0600 (CST)
From:      Jay Nelson <jdn@qiv.com>
To:        "Matthew D. Fuller" <fullermd@futuresouth.com>
Cc:        Satoshi Asami <asami@cs.berkeley.edu>, richard@pegasus.com, stable@FreeBSD.ORG
Subject:   Re: Partitioning
Message-ID:  <Pine.BSF.3.96.971107203247.1158A-100000@acp.qiv.com>
In-Reply-To: <Pine.BSF.3.96.971107195505.1994A-100000@shell.futuresouth.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.971107203247.1158A-100000>