Subject: RE: [nfsv4] comments on draft-welch-pnfs-ops-00.txt

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 16 Nov 2004 20:31:56 -0500

It will give you many of the benefits of file-level reverral but it
isn't exactly a referral in that the metadata server maintains
control of the metadata and can recall the layout at any time.

The interesting point is that while much of the pnfs discussion
discusses the benfits of parallelism in terms of striping large
files among data repositories, there is also a benefit for 
environments in which file sizes are more moderate and only consist 
of a single stipe.  In that case there can be parallelsim due 
to the fact that files from the same fs are distributed among
a set of data servers.

-----Original Message-----
From: Marc Eshel [mailto:[email-masked]]
Sent: Tuesday, November 16, 2004 6:17 PM
To: Nicolas Williams
Cc: Noveck, Dave; Mike Eisler; [email-masked]; Trond Myklebust; Brent
Welch
Subject: Re: [nfsv4] comments on draft-welch-pnfs-ops-00.txt

Nicolas Williams <[email-masked]> wrote on 11/16/2004 02:17:43
PM:

> On Tue, Nov 16, 2004 at 05:13:40PM -0500, Trond Myklebust wrote:
> > ty den 16.11.2004 Klokka 12:30 (-0600) skreiv Nicolas Williams:
> > > On Tue, Nov 16, 2004 at 01:14:46PM -0500, Noveck, Dave wrote:
> > > > So the question is, how do you create a meaningful requirement?
> > > > OK, it's mandatory to provide a NFSv4-style layout.  Nothing could
> > > > be simpler.  The layout for file handle FH says that the data is
> > > > at FH' and IP address X (one of the servers IP addresses) and your
> > > > done.  Is that OK?  The performance of accessing the data using
> > > > that layout will be no better than accessing it over standard
> > > > NFSv4, but do we want to get in the business of making performance
> > > > requirements?
> > >
> > > Huh?  Why couldn't the meta-data server say
> > >
> > > [{fs_location1, FH', byte-ranges}, {fs_location2, FH', byte-ranges},
..,
> > >  {fs_locationN, FH', byte-ranges}]
> >
> > Yech. That is potentially an *unbounded* list.

> No, it's not.  It's clearly bounded *and* this is exactly the sort of
> thing that was presented last week at the meeting, only there the
> emphasis was on blocks.

> Nico
> --

This is great we get file level referral with {fs_location, FH',
byte-ranges( 0 - infinity )}
which is good among other things for load balancing.

Marc.

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

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

---

From: Chenggong Charles Fan <[email-masked]>
Date: Tue, 16 Nov 2004 17:58:51 -0800

I echo Marc and Dave.  It will be interesting to have file-level referal 
as one of the use cases for pNFS, in the case actual storage server is 
also NFSv4 and {fs_location, FH', byte-ranges( 0 - infinity )}  I think 
as long as pNFS spec doesn't prevent an implemention where meta-data 
server provides only location/layout information but performs no 
file-level access control, and actual access control is only performed 
on the "backend" NFSv4 storage server, we'll get the file-level referal 
feature for free. 

Charles

---

From: Julian Satran <[email-masked]>
Date: Wed, 17 Nov 2004 09:27:35 +0200

> to the fact that files from the same fs are distributed among

I would add to it also that this is allows you to handle a single 
namespace in the central pNFS server and the "data servers" become less 
relevant in naming (from a application perspective). I also agree with 
Craig that credentials are a better way to handle access control that 
replicating ACLs and limiting credentials to Object Storage would be bad 
(I advocate a "common" security infrastructure for all storage modes 
(including block - where a volume credential may be supported in-band or 
out-of-band).