From owner-freebsd-hackers Tue Oct 8 11:57:34 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA16191 for hackers-outgoing; Tue, 8 Oct 1996 11:57:34 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA16173 for ; Tue, 8 Oct 1996 11:57:22 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA16700; Tue, 8 Oct 1996 11:52:16 -0700 From: Terry Lambert Message-Id: <199610081852.LAA16700@phaeton.artisoft.com> Subject: Re: VPS mailing list, BSD interest? To: avalon@coombs.anu.edu.au (Darren Reed) Date: Tue, 8 Oct 1996 11:52:16 -0700 (MST) Cc: terry@lambert.org, avalon@coombs.anu.edu.au, jrg@demon.net, mrg@eterna.com.au, hackers@FreeBSD.org, tech-kern@netbsd.org In-Reply-To: <199610081022.DAA02491@coyote.Artisoft.COM> from "Darren Reed" at Oct 8, 96 08:21:44 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > A FS type must be able to express a preference or deny an underlying > > media type. For instance, FFS should be permitted to prevent you > > putting it on a device which has Logical Device Attributes of > > LDA_MAY_GROW or LDA_MAY_SHRINK, since handling of these operations > > requires that the FS register a callback to allow or veto the > > operation, depending on whether or not it has handlers. > > Why should it care about whether what is beneath it can grow/shrink ? Morally, or technically? Morally, it shouldn't. Technically, it will if the design of the FS didn't include the possibility that the underlying storage may grow or shrink. Grow, well, you can ignore the exra space. Shrink, you're pretty much screwed, blued, and tatooed. > It might care if actually happens or something tries to make it happen, > but otherwise it shouldn't care. > > If I create a FFS on some logical volume, then maybe a flag in the > filesystem should be set to disallow changes. The change attempt is an event. It is this event which must be disallowed. > My desire is this: to be able to put a file system on or across any span > of disk space, when I like and when I want. If it must be in increments > of 4, 8 or 16MB, so what. If this happens to be 40MB that is spread > across 4 disks in 10MB bits, so what ? The LVM should be able to manage > that and present it to the FFS code as one contiguous area of disk. That's not, strictly speaking, an LVM. It's a volume spanning architecture. LVM includes more than simple volume spanning (like CCD). If it didn't, we might as well just cannonize CCD and be done with it. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.