Charles M. Hannum writes:
> 
> Michael Graff <explorer@flame.org> writes:
> > And just how would you suggest this be done?
> > 
> > If I link in the ffs system automatically, that's ok.  If the mfs
> > LKM contains the ffs code internally, then you're screwed when you try
> > to load both mfs and ffs due to duplicate symbols.
> 
> It seems to me that the real answer here is to make MFS go away, and
> change mount_mfs to create a rd device and mount it.  (We'd also need
> a umount_mfs to garbage collect the rd device.)

I subtly disagree. MFS should not be kept as is, but...

We have a need for an MFS like construct. The problem with both the RD
driver and the MFS driver is that neither really takes advantage of
the fact that ramdisks are NOT real disks -- both just lay out an FFS
in memory, which is silly, since the engineering constraints that
built FFS aren't present in a RAM based filesystem. This leads to all
sorts of waste.

I would like to see a new MFS built that actually can grow and shrink
its use of real memory and which takes solid advantage of the fact
that RAM is not disk to optimize allocation.

Perry