From: Mike Eisler (mre@eng.sun.com)
Date: 08/12/99-09:51:11 AM Z
Date: Thu, 12 Aug 1999 07:51:11 -0700 (PDT)
From: Mike Eisler <mre@eng.sun.com>
Subject: RE: Caching issue (SHORT, really, I swear)
Message-ID: <Roam.SIMC.2.0.6.934469471.24566.mre@eng.sun.com>
> How about this? What is now the filesize limit become a
> structure space_limitation whose current realization is
> just a filesize limit but will be flagged as intended
> for extension. The spec will make it clear that
> the architecture is one in which the server passes a
> small set of data which the client can use to determine,
> given the data it has, whether the flush needs to occur.
> The filesize-limit-only implementation would be a
> placeholder which would become the real implementaion
> only if all of the (seemingly) better alternatives
> don't pan out.
I'd like people to think about alternatives now, to increase the chances that
a viable alternative will pan out.
I propose a slight change to above and that is that the discriminated union
space_limitation include both a file size limit and block reservation limit,
now. The block reservation limit is flagged as subject to change pending
implementation experience.
enum limit_by4 {
NFS4_SIZE = 1,
NFS4_DIRTY_BLOCKS = 2 /* experimental. subject to change */
/* others as needed */
};
struct nfs4_dirty_limit {
unsigned hyper bytes;
unsigned int blocksize;
} ;
union nfs4_space_limit switch (enum limit_by4 limitby) {
case NFS4_SIZE:
unsigned hyper filesize;
case NFS4_DIRTY_BLOCKS:
nfs4_dirty_limit dirtyblocks;
} ;
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:29 AM Z CST