> >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.
> 
> It would actually break FFS for a partition to grow underneath it?

Er.  Define "break".  If you mean "cause to cease functioning", no.
If you mean "damage ability to function as designed", yes.  The
difference is subtle, since you will store and retrieve file normally
(assuming you hack the on disk FS structure to add the space), but
may seriously damage the efficiency with which new data can be stored
or retrieved.

If I partially kink a hose, it doesn't "break" it, but you don't get
nearly as much water moving through the thing.

> I mean, it be pretty pointless to make a partition larger than the filesystem
> if the fs can't grow. 

Well, it won't "break" in that sense.  If you don't hack the on disk FS
structure, then the FS will simply ignore the space.  I suppose that,
technically, that's not broken either.

> Hmmm. I see your point. Shrinking would be the harder case.

8-).

> Would newfs_ffs (or whatever) know which devices could support the 
> filesystem? How would that work?

Give attribute flags as a result of the logical-to-physical or the
logical-to-logical translation layer(s) you interpose, and have the
FS "prefer" FS's with or without particular flags.

> >Similarly, JFS/NTFS/LFS/etc. which can handle changing agregation
> >sizes with an LVM facility (adding or deleting PP's from the volume)
> >must call back to determine allowable size change increment.  I believe
> >JFS requires a 4M or an 8M increment, in all cases, for instance.
> 
> Lemmie see if I have this straight:
> 1) User program decides to grow/shrink a partition.
> 2) User program tells partition to grow/shrink
> 3) Virtual partition asks for the permission of the filesystem
> 4) Assuming they agree, they work together somehow to do whatever
>   -- Filesystem must make sure there is enough space available to 
>      shrink down into. Non-resizable filesystems would just veto
>      the whole shebang.
> 
> Is that the gist of it? 

"Work together somewhow" is probably too fuzzy a decription.  Consider
X window managers (like Motif) which can pich and choose vertical and
horizontal "snap" increments (ie: an xterm which can only resize on a
character cell boundry).  It's the same thing; you provide allowable
and preferred values.  Preferred values are a set intersecting the set
of allowable values, but potentially smaller, since the FS may say
"you CAN do this, but I'd RATHER you do that".

> Ok. Doesn't this assume that whatever is sitting on top of the partition
> is a filesystem? What if it isn't? What if a database or something or
> other is sitting on top? Would resizing be possible? Wouldn't the mechanism
> of communicating the resize be different because of the user program 
> hitting the disk instead of going through a filesystem?

You would only allow vetted changes.  I there was a database (actually,
a private FS for a database) there, then the change would probably not
be vetted.  If it's not vetted, it's disallowed (and a veto is given
using the default vetting code).


> Third case: What do you do about resizing a swap partition? Can the
> FreeBSD VM system move swapped out pages out of the way of a resize?
> How would the partition tell the VM system to move? I guess this might
> be through the same system as a kernel-based filesystem.

Yes.  The VM system would register with the partition management
framework.  You need this anyway so that when a swap region is in
use, you do not resize it or delete it out from under the VM system
(which would be Bad).


> Hmmmmm. Know of any good books on the subject? (Chris Dukes the other day
> asked on the ncsu.os.linux newsgroup if anybody knew of a good class
> offered by our Computer Science department. If there were any responses, they
> didn't appear on the newsgroup. Hmmmmm.) (No, there is no ncsu.os.bsd. I
> guess you can't have a newsgroup for, like, 3 people). 

Which subject?  You've hit about 5 or 6 of them here.  8-).


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.