Subject: RE: [nfsv4] pNFS issues/changes (draft-welch-pnfs-ops-02.txt)

From: [email-masked]
Date: Wed, 6 Jul 2005 09:02:29 -0400

Jim,

I understand that asking for read vs. write (read-write) access
in the layout get operation is important so that the object layout
contains a capability (or capabilities) that is (are) useful to
the client, and this is even potentially useful for files ... BUT
does the object layout ever simultaneously need different layout
info for read and write of the same offset (cf. the valid read
data in one place, invalid data to be written elsewhere case
for the block layout below).  I could perhaps see wanting this
to allow a client to cache a read capability across a short
write period, but I don't know how useful/important that is for
objects.

Thanks,
--David

> Read versus write distinctions for layout identification
> are important for objects as well. I think it's the case
> that it's only don't-care for files.
> 
> -Jim Zelenka
> 
> >> 3.3.1 Identifying layouts
> >> 
> >> Proposal: layouts are identified by <ClientID, FH, offset, length>
> >>  
> >> Alternative: may need to distinguish between read vs. read/write layout

> >> types, e.g., block/obj layouts may have separate read vs. read/write 
> >> layouts and will want to handle them separately.  Propose adding iomode

> >> to layout identification (and allowing recall to specify the specific 
> >> mode or any mode).
> >
> >At least for the block layouts, read vs. write would be opaque to pNFS
> >- we'd hand back extra data structure in the layout to get this done.
> >An important case in the block world is that the read block is valid
> >and read-only, but the write block is invalid until written.  OTOH,
> >I'm not sure I can get the details of how to do this into the block
> >draft in time for Paris.  This may be block-only, as this particular
> >issue (reads have to go to a different place than writes for correctness)
> >probably does not occur in files or objects.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Marc Eshel <[email-masked]>
Date: Mon, 18 Jul 2005 19:14:03 -0700

"Noveck, Dave" <[email-masked]> wrote on 06/21/2005 01:51:07 PM:

> > With fs-locations we give the client a list of metadata server 
> > that can act as the server for given filesystem and the client 
> > can choose which one to use and switch among them at will or 
> > because of some failure. 
> 
> The problem is that in v4.0 as it stands there is an enormous
> range of ways that a client can interpret the fs_locations list:
> 
> "Here is a list of servers and you can switch when there is failure,
> after refetching your change attibutes (because change attribute
> is within the purview of a particular server)."  (and that is not the
> most extreme case of discontinuity -- some people are thinking that 
> filehandles and fileids will just change or that you may wind up
> with a slighly out-of-data version of the data).
> 
> "Here is a list of servers and you can switch when there is a 
> failure with no discontinuity of access (changes in fh's, stateid's,
> fileids, change attributes), although changing is a big deal
> and you shouldn't do it without good cause."
> 
> "Here is a list of servers and you can switch when there is a
> failure with no discontinuity of access or even at will since
> there is no big cost to switch."
> 
> "Here is a list of servers and you can access any of these 
> servers as you will at the same time (multi-pathing or a 
> cluster fs) since they are all effectively the same thing".
> 
> The problem is that the client only knows about the list and
> has no way of knowing which of the statements above is associated
> with the list of servers he is getting.  I have been thinking
> about a locations_info attribute for 4.1 that would allow the
> server to tell the client which of those he meant and also 
> give preference information (local vs. remote copies, absolutely
> up-to-data vs. slightly out-of-data copies).
> 
This sound like a good idea. Do you still have time to start new 
extensions for 4.1?
Marc.