From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 18:36:32 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 A1B6016A41F for ; Fri, 18 Nov 2005 18:36:32 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 581F843D45 for ; Fri, 18 Nov 2005 18:36:32 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id C6F2446B92; Fri, 18 Nov 2005 13:36:31 -0500 (EST) Date: Fri, 18 Nov 2005 18:36:31 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alexander Leidinger In-Reply-To: <20051118130223.z87u1gbswwg0kckw@netchild.homeip.net> Message-ID: <20051118183115.V52197@fledge.watson.org> References: <20051118114308.GA11281@uk.tiscali.com> <20051118130223.z87u1gbswwg0kckw@netchild.homeip.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, Brian Candler 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 18:36:32 -0000 On Fri, 18 Nov 2005, Alexander Leidinger wrote: >> - What I'm suggesting may or may not look like Linux's LVM; I've never >> used that. If its data structure is suitable, we can just use that and >> gain some compatibility for multi-boot systems. > > This statement is a little bit simplified, but you're describing a > stripped and crippled down version of Solaris ZFS (at least from the > functionality point of view). I think we find ourselves faced with an interesting question: in the past, logical volume management has been done at one of two levels. It's been extensively explored at the block device level -- a large number of volume managers have subdivided, mirrored, managed, etc, chunks of storage which are then exposed as a single contigous logical volume to higher level file system code. In the past, and especially recently with ZFS, file systems have also become involved. For example, AFS provides a logical volume notion that is a high level abstraction in the file system, permitting migrating of components of a global name space between services, quotas, etc. Advantages to doing it at the block storage level are that the implementations tend to be relatively simple, and pretty robust. However, they also tend to be fairly naive with regards to storage requirements relating to file systems: you are forced to "hard allocate" resources to name space components, the higher level file system still requires support for notions such as size changes, etc. Disdvantages are that your file system code becomes a lot more complicated. Implementing basic logical volume managements as a series of GOEM classes shouldn't be too hard -- the most difficult bit is configuration management and the management of long-running operations that may be interrupted by reboot, hardware failure, etc (replicating data, migrating volumes, and so on). You may need things like journaled configuration and so on. However, as recent discussion of ZFS illustrates, you can get some really nice benefits from tight integration -- logical file system volumes that offer layout-based quotas, reliability or performance properties based on location in the name space, etc. Robert N M Watson