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

fan@rainfinity.com

Message-ID: <419AB05B.5000600@rainfinity.com>
Date: Tue, 16 Nov 2004 17:58:51 -0800
From: Chenggong Charles Fan <fan@rainfinity.com>
Subject: Re: [nfsv4] comments on draft-welch-pnfs-ops-00.txt

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

Noveck, Dave wrote:

>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:eshel@almaden.ibm.com]
>Sent: Tuesday, November 16, 2004 6:17 PM
>To: Nicolas Williams
>Cc: Noveck, Dave; Mike Eisler; nfsv4@ietf.org; Trond Myklebust; Brent
>Welch
>Subject: Re: [nfsv4] comments on draft-welch-pnfs-ops-00.txt
>
>
>
>
>
>
>
>
>Nicolas Williams <Nicolas.Williams@sun.com> 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
>>nfsv4@ietf.org
>>https://www1.ietf.org/mailman/listinfo/nfsv4
>>    
>>
>
>
>_______________________________________________
>nfsv4 mailing list
>nfsv4@ietf.org
>https://www1.ietf.org/mailman/listinfo/nfsv4
>  
>

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4