From: Benny Halevy <bhalevy@panasas.com>
To: Jim Rees <rees@umich.edu>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>,
linux-nfs@vger.kernel.org, peter honeyman <honey@citi.umich.edu>
Subject: Re: state manager failed on NFSv4 server
Date: Thu, 13 Jan 2011 15:23:43 +0200 [thread overview]
Message-ID: <4D2EFCDF.8060507@panasas.com> (raw)
In-Reply-To: <20110113005439.GA15550@merit.edu>
On 2011-01-13 02:54, Jim Rees wrote:
> Trond Myklebust wrote:
>
> > At the time of the EXCHANGE_ID call, how is the server supposed to know what
> > kind of layout is going to be negotiated? It doesn't yet know whether the
> > client is even going to ask for a layout, does it?
>
> It doesn't matter. EXCHGID4_FLAG_USE_PNFS_MDS is the server's way of
> advertising to the client that it supports LAYOUTGET and other pNFS
> related operations. The client is free to ignore that message if it so
> desires, and just use read/write through MDS. The point here is to tell
> the client whether or not it should try pNFS if it can.
>
> I guess that makes sense. But I think section 13 is a bit misleading since
> it contains requirements for the block layout too.
True, but section 18.35. Operation 42: EXCHANGE_ID - Instantiate Client ID
specifically says:
The EXCHGID4_FLAG_USE_NON_PNFS, EXCHGID4_FLAG_USE_PNFS_MDS, and
EXCHGID4_FLAG_USE_PNFS_DS bits are described in Section 13.1 and
convey roles the client ID is to be used for in a pNFS environment.
The server MUST set one of the acceptable combinations of these bits
(roles) in eir_flags, as specified in Section 13.1.
Benny
>
> 13. NFSv4.1 as a Storage Protocol in pNFS: the File Layout Type
>
> This section describes the semantics and format of NFSv4.1 file-based
> layouts for pNFS. NFSv4.1 file-based layouts use the
> LAYOUT4_NFSV4_1_FILES layout type. The LAYOUT4_NFSV4_1_FILES type
> defines striping data across multiple NFSv4.1 data servers.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-01-13 13:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-12 18:58 state manager failed on NFSv4 server Jim Rees
2011-01-12 19:13 ` Trond Myklebust
2011-01-13 0:07 ` Jim Rees
2011-01-13 0:18 ` Trond Myklebust
2011-01-13 0:30 ` Jim Rees
2011-01-13 0:37 ` Trond Myklebust
2011-01-13 0:54 ` Jim Rees
2011-01-13 13:23 ` Benny Halevy [this message]
2011-01-12 19:15 ` Andy Adamson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D2EFCDF.8060507@panasas.com \
--to=bhalevy@panasas.com \
--cc=Trond.Myklebust@netapp.com \
--cc=honey@citi.umich.edu \
--cc=linux-nfs@vger.kernel.org \
--cc=rees@umich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.