From owner-freebsd-hackers  Thu Oct  3 01:44:30 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id BAA15078
          for hackers-outgoing; Thu, 3 Oct 1996 01:44:30 -0700 (PDT)
Received: from ub4b.eunet.be (ub4b.eunet.be [192.92.130.1])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA15070
          for <hackers@freebsd.org>; Thu, 3 Oct 1996 01:44:26 -0700 (PDT)
Received: from gate.eurocontrol.be by ub4b.eunet.be (ub4b_08)
	id AA28125; Thu, 3 Oct 1996 10:44:11 +0200
Received: by gate.eurocontrol.be
	(1.37.109.18/16.2) id AA002375887; Thu, 3 Oct 1996 10:44:47 +0100
Received: from biscuit.eurocontrol.be(193.221.170.198) by gate.eurocontrol.be via smap (V1.3)
	id sma000233; Thu Oct  3 10:44:21 1996
Received: from dolphin.pst.cfmu.eurocontrol.be by biscuit.eurocontrol.be with ESMTP
	(1.37.109.18/16.2) id AA104435841; Thu, 3 Oct 1996 10:44:01 +0100
Received: from heron.pst.cfmu.eurocontrol.be by dolphin.pst.cfmu.eurocontrol.be with SMTP
	(1.37.109.16/16.2) id AA137822223; Thu, 3 Oct 1996 10:43:43 +0200
To: "Kevin P. Neal" <kpneal@pobox.com>
Cc: Terry Lambert <terry@lambert.org>, avalon@coombs.anu.edu.au (Darren Reed),
        jrg@demon.net, mrg@eterna.com.au, hackers@freebsd.org,
        tech-kern@netbsd.org
Subject: Re: VPS mailing list, BSD interest? 
In-Reply-To: Your message of "Thu, 03 Oct 1996 01:08:55 EDT."
             <1.5.4.32.19961003050855.006b6f70@mindspring.com> 
Date: Thu, 03 Oct 1996 10:43:41 +0200
Message-Id: <9968.844332221@heron.pst.cfmu.eurocontrol.be>
From: Jim Reid <jim.reid@eurocontrol.be>
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>>>>> "Kevin" == "Kevin P Neal" <kpneal@pobox.com> writes:

    Kevin> It would actually break FFS for a partition to grow
    Kevin> underneath it?

Not necessarily. For those who are unfortunate to have LVM, there is a
utility called extendfs which allows you to expand the filesystem -
here it's just ufs, but I suppose would work for vxfs too - into new
logical volumes.

    Kevin> Would newfs_ffs (or whatever) know which devices could
    Kevin> support the filesystem? How would that work?

I guess it works by having some kernel struct which has a number of
block counts and disk devices and offsets which comprise each logical
volume.

    Kevin> Lemmie see if I have this straight: 1) User program decides
    Kevin> to grow/shrink a partition.  2) User program tells
    Kevin> partition to grow/shrink 3) Virtual partition asks for the
    Kevin> permission of the filesystem 4) Assuming they agree, they
    Kevin> work together somehow to do whatever -- Filesystem must
    Kevin> make sure there is enough space available to shrink down
    Kevin> into. Non-resizable filesystems would just veto the whole
    Kevin> shebang.

Not exactly. In the LVM paradigm, physical volumes - disks or bits of
disks can be added and removed from a logical volume more or less at
will. [Obviously there are sanity checks that the PV isn't used.] Once
you've added a new PV to the logical volume, extendfs is used to
diddle the superblocks so the filesystem can use the new space.

    Kevin> Ok. Doesn't this assume that whatever is sitting on top of
    Kevin> the partition is a filesystem? What if it isn't? What if a
    Kevin> database or something or other is sitting on top? Would
    Kevin> resizing be possible? Wouldn't the mechanism of
    Kevin> communicating the resize be different because of the user
    Kevin> program hitting the disk instead of going through a
    Kevin> filesystem?

It depends on what it's being used for.

    Kevin> Third case: What do you do about resizing a swap partition?

This is hardly different from adding an extra swap device. Just add a
vnode which points at the extra space and use swapon to make the
kernel use it.