Re: Approaches to storage allocation

[Jonathan S. Shapiro]

On Wed, 2005-10-12 at 22:33 +0100, Neal H. Walfield wrote:
>  
> > To simplify the protocols, it is normal for the client to specify a
> > space bank at object creation time. The server associates this bank with
> > the object for later use when that object is extended, grown, or shrunk.
> 
> How does the client determine how large a space bank to hand to the
> server?  In the case of an object upon which the client depends, I can
> see the argument that no limit need be provided.  On the other hand, a
> task might have a number of resources that it would like to use but
> doesn't depend on.  If it gives unlimited access to its space bank
> then one misbehaving server can create a denial of service.

The answer is: in the absence of a storage requirement specification you
can't figure it out.

But in practice the right solution is to invert the problem. Ensure that
you know the storage required for your process manager window. Let
everything else run unlimited.

Here is how this works:

Space banks form a tree. The effective limit on a bank is the *least*
limit of all of its parents. It is legal to build a parent with a limit
of 2 and a child bank of this parent with a limit of 18. All space banks
are actually implemented by a single server process, so the tree
traversal does not involve any context switches.

It is also legal to build *unlimited* banks, and these can be children
of limited banks. This does not mean that allocation is unlimited. It
merely means that no limit is imposed by the unlimited bank.

So in practice, the thing to do is have the shell run each program in a
dedicated, unlimited sub-bank. If the program goes crazy, you destroy
the bank. When you destroy the bank, all of the storage is destroyed
too.

I guess what I am saying is: Alfred is right. Either you know what the
space requirement is or quotas are stupid. In a general-purpose system,
the bad behavior is going to happen rarely enough that you can deal with
it on an exceptional basis. You just want to make sure that you have a
destroyable bank in place that you can use to kill the misbehaving
process(es).

> What does the server do when it requires more storage but the space
> bank is full?

Current behavior: When the limit is exceeded, allocation fails.

Norm Hardy and I have discussed a design in which a fault handler could
be associated with a limited bank that might be invoked to try to
resolve the problem. Norm had some concerns about this related to covert
storage channels. This is a case where he and I do not fully agree. I
believe that the value of recoverability in this situation outweighs the
risk of the storage channel.

However, there are some classified system configurations in which this
decision might need to be made the other way.


shap