From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 12:59:38 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F6AC16A420 for ; Fri, 18 Nov 2005 12:59:38 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AD2F43D7E for ; Fri, 18 Nov 2005 12:59:26 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id 324FA801; Fri, 18 Nov 2005 07:59:47 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id E35C68A; Fri, 18 Nov 2005 07:59:45 -0500 (EST) Received: from brian by mappit.local.linnet.org with local (Exim 4.54 (FreeBSD)) id 1Ed5pq-00033J-Jn; Fri, 18 Nov 2005 12:59:22 +0000 Date: Fri, 18 Nov 2005 12:59:22 +0000 From: Brian Candler To: Eric Anderson Message-ID: <20051118125922.GA11684@uk.tiscali.com> References: <20051118114308.GA11281@uk.tiscali.com> <437DCB6D.6090400@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <437DCB6D.6090400@centtech.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: Logical volume management X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2005 12:59:38 -0000 On Fri, Nov 18, 2005 at 06:39:09AM -0600, Eric Anderson wrote: > - volume migration (online) Perhaps there are two primitive operations: 1. move an individual chunk from device A to device B (LVM calls these chunks "extents" BTW, which is probably a better name; it has a long history going back to mainframe storage systems) 2. move an entire volume The second of these could be done by creating a new volume, mirroring it with the first, and then removing the first volume from the mirror set. > - auto block allocation (assigning blocks from the pool to a volume as > needed) I think that requires interaction with the underlying filesystem if it is to happen automatically. I'd be quite happy with a two-step process: increase the size of a volume manually, then run growfs to make the filesystem fit the new space. Pity there's no shrinkfs... > It would be nice to be able to create an arbitrarily large volume, which > only uses these volume blocks (you call them chunks) as the volume > gets filled. This way, you could create a 2Tb volume, with only a > single 200Gb drive, then as you neared the 200Gb used mark, you could > add another disk, and grow on to it Maybe. However I don't see the advantage of this compared to creating a 200GB volume, and then as it nears getting full expand it to 400GB, and so on. I can see a number of downsides to your approach: - df will lie. You may think your filesystem is only 10% full, when in fact it is about to fail due to lack of space. - partitioning has an important administrative use, to enforce limits. That is, one of the reasons I keep /var on a separate partition is so that if it fills, it doesn't stop the OS from creating files in / or /tmp etc, so it's easier to recover from whatever problem was filling /var in the first place. So if you have an 80GB drive and you created an 80GB /, an 80GB /var, an 80GB /usr and 80GB /home, allowing each of them to expand to fit as needed, then you might as well just have created a single 80GB / in the first place, mightn't you? > Maybe we should take this to freebsd-geom@? Good idea. Regards, Brian.