From owner-freebsd-hackers  Tue Oct  8 03:23:14 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id DAA16371
          for hackers-outgoing; Tue, 8 Oct 1996 03:23:14 -0700 (PDT)
Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA16358
          for <hackers@FreeBSD.org>; Tue, 8 Oct 1996 03:23:08 -0700 (PDT)
Message-Id: <199610081023.DAA16358@freefall.freebsd.org>
Received: by cheops.anu.edu.au
	(1.37.109.16/16.2) id AA122850104; Tue, 8 Oct 1996 20:21:44 +1000
From: Darren Reed <avalon@coombs.anu.edu.au>
Subject: Re: VPS mailing list, BSD interest?
To: terry@lambert.org (Terry Lambert)
Date: Tue, 8 Oct 1996 20:21:44 +1000 (EST)
Cc: avalon@coombs.anu.edu.au, jrg@demon.net, mrg@eterna.com.au,
        hackers@FreeBSD.org, tech-kern@netbsd.org
In-Reply-To: <199610022154.OAA04828@phaeton.artisoft.com> from "Terry Lambert" at Oct 2, 96 02:54:20 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

In some mail from Terry Lambert, sie said:
> 
> > Hmmm, having used LVM, seen ccd docs, to me, it should be something
> > like this:
> > 
> > +----------------------------------+
> > |   FFS/UFS/NTFS/LFS/VXFS/EXT2/... |
> > +------------------+---------+-----+
> > |                  |  LVM    |     |
> > |       disks      +---+-----+ CCD |
> > |                      |           |
> > |    hd* sd* xd*       +-----------+
> > |                                  |
> > +----------------------------------+
> 
> Ugh.
> 
> 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 ?

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.

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.

Darren