Date: Sat, 13 Mar 2004 12:29:33 +0000 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: freebsd-questions@freebsd.org Subject: Re: resizing partitions in the same slice Message-ID: <20040313122933.GC98015@happy-idiot-talk.infracaninophile.co.uk> In-Reply-To: <20040312230210.GC16477@Dark-Age.local> References: <20040312184702.GA16477@Dark-Age.local> <200403121922.i2CJMLa19763@clunix.cl.msu.edu> <20040312230210.GC16477@Dark-Age.local>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
On Fri, Mar 12, 2004 at 05:02:10PM -0600, Eugene Lee wrote:
> I'm a little surprised. I would think that resizing partitions is a
> common request, that the idea of growing one partition while shrinking
> another is not a new or rare notion. Can anyone else share their views
> or experiences? The list archives contain few comments on the subject.
Absolutely. This is something that there is a great deal of pent up
demand for. Consequently growfs(8) exists, which can extend a
filesystem. Normally growfs(8) is used in a RAID environment, where
extra space can be added to a slice relatively easily. However, it
can certainly be used on a regular harddrive. You'll need to re-do
the partitioning as a separate job, and be very careful about the
whole job, as a misstep will possibly trash the whole disk.
While growfs(8) does it's job very well, there's some obvious areas
where it's functionality could be extended. The first would be a
mechanism for being able to run growfs on a mounted filesystem.
That's hugely important for fileservers with very large filesystems
and hundreds of network clients. Models for how to do this already
exist: for instance see the lockfs(1M) implementation from Solaris:
http://www.freebsd.org/cgi/man.cgi?query=lockfs&apropos=0&sektion=0&manpath=SunOS+5.9&format=html
The other obvious extension is 'shrinkfs' which at the moment can only
be achieved by backing up the partition and restoring it into a
smaller space. The problem with shrinkfs is that it requires shifting
the on-disk data into a smaller region, something which is
intrinsically much more difficult than just providing an extra chunk
of empty space. As far as I know, no one has yet managed to produce a
working shrinkfs implementation under any sort of Unix or Unix derived
system.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks
Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
Tel: +44 1628 476614 Bucks., SL7 1TH UK
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD4DBQFAUv6tdtESqEQa7a0RAkULAJoCmkZcP6MPfpIpjpYU8mx6iUdEsgCY7HWA
pmqF1oOUKkVnrjHpEjzkOw==
=aNm/
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040313122933.GC98015>