Subject: regarding delegations

From: kvs sivak <[email-masked]>
Date: Sun, 14 May 2000 12:51:39 +0100 (BST)

hi ,
 In implementing delegations what are the proper
semantics to be followed in the below scenarios :

1. A client is given a READ DELEGATION when a file is 
 opened. how does the CLIENT obtain the file data
initially ??
  a) As soon as delegated it reads the file data from
the server and caches it.
  b) Data arrives on the client ONLY WHEN the first
read request comes. this first read causes the client
to fetch the required data from the server (SUBSEQUENT
reads for THIS data are NOT SENT to the server in this
case ).

option b seems more logical and correct ..

2. A client is given a WRITE DELEGATION on a file .
now subsequent open's are processed by the CLIENT
itself. IF many processes at the client make
modifications at different offsets in the file ,what
should be the method adopted by the client to
guarantee CONSISTENCY of data to its various
processes:
  a) The client caches the changes locally and for any
read calls checks its cahces for updated data  and
returns the update data ..( This seems most IMPOSSIBLE
b'cos there is NO LIMIT on how much data the client is
required to cache ...)
  b) The client has a maximum cache size .
modifications are flushed to the server once the cache
size grows beyond this maximum.

____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie

---

From: [email-masked]
Date: Sun, 14 May 2000 16:51:29 -0700

> semantics to be followed in the below scenarios :

There shouldn't be any semantic issues here.  The 
essence of the delegation should be to assure that
for both 1. and 2., a) and b) and other choices are
semantically equivalent.  It is up to the client to
do whatever is most convenient.
 
> option b seems more logical and correct ..

There isn't any correctness issue.  The data can't change
while you have a read delegation outstanding so the results
ar going to be the same.  From an implementation point of
view you don't want to waste bandwidth reading a big file
that is not going to used, so I would wait for the first 
read to read anything more than a single block and then 
read a fairly large amount after that but not the whole
file if it was enormous.  This is all client implementation
choice, rather than semantics.  You just have to make sure
that if you read a lot of data ahead, you throw it away if
the delegation is recalled.

> size grows beyond this maximum.

For correctness, you have to check dirty data in your cache
before sending a read to the server.  However, you are free
at any time to write dirty data in your cache to the server.
Once the data is written and committed to stable stroage,
you can eliminate from your cache, or at least mark it is
not dirty.  Clearly, since your cache is not infinite,
you have to do this at some point, but the protocol doesn't
specify when you do it.  The only thng you need to do for
correctness, is flush the dirty data when the write delegation
is reaclled.  As long as the write delegation is in effect,
no other client can read the file so it can never see an
inconsistent state in which only some of your changes have 
been sent to the server.