Subject: Re: [nfsv4] Metadata striping

From: "Mike Eisler" <[email-masked]>
Date: Mon, 1 Dec 2008 07:02:45 -0800 (PST)

On Wed, November 19, 2008 11:55 am, Peter Braam wrote:
> Pardon my ignorance of NFS and the intrusion.  When reading through the
> metadata striping document (
> http://tools.ietf.org/id/draft-eisler-nfsv4-pnfs-metastripe-01.txt ) the
> following thoughts and questions came up.
>
> The attributes of a file can be summarized as:
>
> Its identifier as entered in directories, let¹s call this a fid
> The core file attributes, such as owner, mode, pointers to extended
> attributes
> Further attributes, such as layout information
> The data in the file
>
> I think I understand how further attributes and data location can be
> specified with a layout associated with the file.   When striping metadata
> the first question that comes up is the layout of the core file attributes
> (Lustre calls this the location of the FID).  If a file system/protocol
> has
> a lookup function a natural step to take is to
>
> 1. do a lookup of the fid based on parent fid and name
> 2. get the location of the fid  i.e. the places where to find the core
> attributes.
>
> If the namespace is spread over multiple nodes, the result of ³2² is not
> always the same node that held the directory.  Also, the location of the

Potentially.

A client gets a layout on a directory (with filehandle dFH)
from an I-MDS.

The client wants to open a regular file named "foo" in dFH.

Using the algorithm returned in dFH's directory layout, the
client sends a request to the computed L-MDS (call it MDS1) that contains
an OPEN for "foo"  and a metadata LAYOUTGET for "foo". Whether the
metadata layout for "foo" returns an L-MDS that is the same as MDS1
is a property of the underlying file system.

> fid
> can already contain striping information, e.g. having  replicas of the
> core
> file attributes is  a good ting.  How does the proposal leverage this?

The proposal returns a device ID in the layout. The device ID is
mapped to a device address using the NFSv4.1 GETDEVICEINFO operation.
The device address can be a single network address, or an array of
network addresses, where each address is equally capable of
serving up the content covered by the layout.

> Here
> is some speculation as to how this might work.
>
> An operation such as NFS Open probably requires the core attributes, so I
> am

OPEN does not require any attributes before the call, though if the
object is being created, attributes in the arguments are needed.
OPEN does not return any attributes; only GETATTR and READDIR can
return attributes.

> speculating that  open(parent_fh, name, ....) would be sent to an I-MDS
> node
> holding the ³name² section of the parent_fh; then that I-MDS would get
> attributes from a secondary L-MDS to complete the open RPC.   It seems

If parent_fh has a metadata layout for name-based operations, then
OPEN parent_fh, name is sent to the L-MDS that F(name) computes to.
The attributes would come from a secondary L-MDS, but that L-MDS
might be, and hopefully is, the same L-MDS the OPEN was sent to.

> that
> only on subsequent operations the client would be able to contact the
> L-MDS
> directly.  Are there RPCs that the I-MDS is making to obtain the layout of
> the core attributes?

The proposal does not specify the inter-MDS protocol. That's a server
problem.

>
> I wonder if I have missed something or if some clarification about the
> striping of the core data is required.
>
> Thank you.
>
> Peter
>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

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