Subject: Re: ffs fragmentation
To: None <>
From: Ian Dall <>
List: tech-kern
Date: 05/20/1999 11:22:29
Mike Cheponis <mac@Wireless.Com> writes:

  > I think that "swap space reservation" and "DynaSwap" are completely
  > compatible.  It's a matter of setting limits on just how much of the disk
  > will be allowed for swap vs for files; think of it like a slider.

  > Currently, the slider is fixed when you mkfs; but there is no reason that
  > the slider cannot be made dynamic, if desired.

I don't understand what you mean by "currently". Currently on NetBSD
mkfs has nothing to do with swap AFAIK. If you mean a current implimentation
of "DynaSwap" (on what?) requires a mkfs to change the amount available
for swap, then that seems no more flexible that the current repartition
scheme and less flexible than the current "swap to file scheme".

  > Therefore, DynaSwap and "old style" swap are competely compatible!

  > This is the reason I don't understand why people are so vehemently opposed
  > to DynaSwap: It gives you everything that you have now, and it give me
  > (and others who are trying to solve large problems) additional flexibility.

Amongst other thing disk partitions allow for different file systems
optimized for different jobs (think of swap space as a special file
system) and they allow for a crude but effective resource allocation

In the best of all posible worlds the it would be easy to change the
amount of any resource allocated to a particular purpose be it memory
disk or whatever. Further more it should be easy to customise an
algorithm for doing it dynamically (hard limits being a special case
of such an algorithm). In the case of disk space the allocation policy
should place things to optimize performance.

The problem is, doing all this is hard and the hard bit is not the
implementation, it is the design. Unix has traditionally been pretty
crude in terms of resource allocation (compared to say VMS which has
quotas for pretty much every conceivable thing).  Few would argue that
repartitioning disks is the ideal way of reallocating disk space
between swap and file storage, and we now do have the means to swap to
files (albeit with a performance penalty I presume).

Earlier in this thread you said that many things should be a matter of
policy.  I agree with that, but the challenge is to come up with a
easy and flexible means for adminstrators to implement that policy. At
the same time the system should a) incur no significant loss of
performance b) acceptable implementation complexity and c) is a
sufficient improvement to warrant the effort.