How about modifying newfs and then allowing it to be invoked by two
names, newfs, which retains the expected behavior, and growfs, which
performs the growth function.  Solaris users of Veritos volume manager will
be familiar with the growfs command and will thus not mis-understand what
and how it works.
-Brian
On Sep 13,  6:30pm, Konrad Schroder wrote:
} Subject: Re: dynamically growing ffs
} On Tue, 14 Sep 1999, Julian Assange wrote:
} 
} > The code probably belongs more correctly in newfs. the rewriting
} > of new cg's etc is complex enough such that it would be wise to
} > take advantage of code that already understands (fsck_ffs) or does
} > (newfs_ffs) it.
} 
} Well, okay, yes.  I guess the point I'm trying to make is not that the
} code in fsck is not appropriate to the task (it is), but that the
} *location* of fsck may not be, whereas the code could be adapted for use
} in something other than fsck.  (IMO fsck is supposed to check the
} filesystem for consistency, and fix it, and that's all.) 
} 
} So I'm suggesting a `libffs', that could be used to verify whether the fs
} is okay (fsck), or make a new one (newfs), or change an existing one
} (tunefs).  Ideally this filestore information would also be separate from
} filesystem information, but integrated with an also-currently-nonexistent
} caching block I/O library.
} 
} In short, it would be cool if
} 
} 	- fsck_{f,l,ext2}fs all shared the same filesystem (not
} 	  filestore) code;
} 	- {dump,dump_,fsck_,new,tune}f?fs all shared the same
} 	  filesystem and filestore code;
} 	- the separation of function between the various utilities
} 	  remained clear.
} 
} 						Konrad Schroder
} 						perseant@hhhh.org
} 
>-- End of excerpt from Konrad Schroder