Date: Thu, 03 Oct 1996 10:43:41 +0200 From: Jim Reid <jim.reid@eurocontrol.be> 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? Message-ID: <9968.844332221@heron.pst.cfmu.eurocontrol.be> In-Reply-To: Your message of "Thu, 03 Oct 1996 01:08:55 EDT." <1.5.4.32.19961003050855.006b6f70@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> "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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9968.844332221>