Subject: RE: Caching issue (SHORT, really, I swear)

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 12 Aug 1999 07:59:35 -0700

> > 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;
> } ;

Sold.

Unless someone objects to that real soon now, I'd say the issue
is resolved.

---

From: Mike Kupfer <[email-masked]>
Date: Fri, 13 Aug 1999 17:05:56 -0700

> Unless someone objects to that real soon now, I'd say the issue

Mike's proposal works for me, too.

mike