Date: Sat, 9 Dec 2000 00:28:21 +0100 From: Thomas <tomsoft@Netz-Werker.COM> To: "Rogier R. Mulhuijzen" <drwilco@drwilco.nl> Cc: scrappy@hub.org, freebsd-current@freebsd.org, growfs@tomsoft.com Subject: Re: growfs(8) for FreeBSD Message-ID: <20001209002821.58836@Netz-Werker.NET> In-Reply-To: <4.3.2.7.0.20001208204155.00cbee40@mail.drwilco.net>; from Rogier R. Mulhuijzen on Fri, Dec 08, 2000 at 08:45:54PM %2B0100 References: <20001208113836.B32113@cichlids.cichlids.com> <Pine.BSF.4.21.0012080857580.446-100000@thelab.hub.org> <4.3.2.7.0.20001208204155.00cbee40@mail.drwilco.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, In an attempt to resolve that discussion: > > > No, vinum can do this alone. > > > But you couldn't grow the _fs_ after that, so there was no use for > > > this vinum feature. Exactly that was the motivation for writing that utility > >Okay, that is what I said ... "add an n+1 drive to ... and increase the > >size of the file system" ... ... which means basically the same :-) > I still don't see why growfs wouldn't work on a non-vinum volume. It's just > a manipulation of the FS, not of the underlying device. But let's leave > this for the makers of growfs to answer shall we =) again correct, technically it is possible to use growfs on ANY object which has a ufs filesystem structure: vinum volume, a partition on a disk, ccd device, even a flat file provided, that there is some space on the end(!) of that medium which is not yet taken by the ufs structures. So you can use it either with hardware RAID controllers which allow for non destructive extending of the size of existing volumes at the end(!). As well you can use it for vinum volumes. Currently this is only possible for mirrored plexes of any kind, or unmirrored concatenated plexes. All other devices cant be changed without destroying the contents. And you can just give some space in the partition table (disklabel) to an existing partition (at its end) and let the filesystem grow within that bound. A shrinkfs is NOT written. The design allows for writing it, but we currently consider other features much more important, like * growing a mounted filesystem * handling file systems with active snapshots is in * grow in a way that we are always safe to loose the power during the growing (softdep concept) * handle byteorder correct on non intel platform (we don't have any alpha hardware but think ufs on alpha is not ufs on intel) * provide the current funktionality on FreeBSD-4 at least, maybe FreeBSD-3 Thomas -- Th.-H.v.Kamptz Die Netz-Werker GmbH To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001209002821.58836>