[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Approaches to storage allocation
From: |
Neal H. Walfield |
Subject: |
Re: Approaches to storage allocation |
Date: |
Wed, 12 Oct 2005 22:33:56 +0100 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI) |
At Sun, 09 Oct 2005 16:37:59 -0400,
Jonathan S. Shapiro wrote:
> Conceptually, the solution that we use in Coyotos is simple: we place
> the burden of supplying storage on the client rather than on the server.
> In any operation that allocates storage, the client supplies a "Space
> Bank" object from which the server allocates the storage on behalf of
> this client.
>
> 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.
What does the server do when it requires more storage but the space
bank is full? Does it send a reply to the client indicating that it
needs a larger space bank and it is up to the client to provide up
resources or abort the operation?
Thanks,
Neal
- Re: Why COPY != SIMULATED COPY, (continued)
- Why kernel REVOCABLE COPY is difficult, Jonathan S. Shapiro, 2005/10/09
- Re: Why kernel REVOCABLE COPY is difficult, olafBuddenhagen, 2005/10/10
- Re: Why kernel REVOCABLE COPY is difficult, Jonathan S. Shapiro, 2005/10/10
- space banks and DMA, Neal H. Walfield, 2005/10/13
- Re: space banks and DMA, Jonathan S. Shapiro, 2005/10/13
- DMA vs. Persistence, Jonathan S. Shapiro, 2005/10/13
- General driver DMA (in EROS), Jonathan S. Shapiro, 2005/10/13
- Approaches to storage allocation, Jonathan S. Shapiro, 2005/10/09
- Re: Approaches to storage allocation,
Neal H. Walfield <=
- Re: Approaches to storage allocation, Jonathan S. Shapiro, 2005/10/12
- Re: problems with hierarchy: L4 pagers, Neal H. Walfield, 2005/10/17
- Re: problems with hierarchy: L4 pagers, Jonathan S. Shapiro, 2005/10/17
- Re: problems with hierarchy: L4 pagers, Neal H. Walfield, 2005/10/18
- Re: problems with hierarchy: L4 pagers, Jonathan S. Shapiro, 2005/10/18
- Re: problems with hierarchy: L4 pagers, Neal H. Walfield, 2005/10/20
- Re: problems with hierarchy: L4 pagers, Espen Skoglund, 2005/10/18
- Re: problems with hierarchy: L4 pagers, Jonathan S. Shapiro, 2005/10/18
- Re: problems with hierarchy: L4 pagers, Espen Skoglund, 2005/10/18
- Re: problems with hierarchy: L4 pagers, Jonathan S. Shapiro, 2005/10/19