On Wed, Feb 15, 2012 at 04:36:34PM -0500, Chuck Lever wrote:
> The fh_expire_type file attribute is a filesystem wide attribute that
> consists of flags that indicate what characteristics file handles
> on this FSID have.
>
> Our client won't support volatile file handles, but it should find
> out at mount time whether the server is going to play shenanighans
> with file handles during a migration.
>
> Signed-off-by: Chuck Lever <chuck.lever@xxxxxxxxxx>
> ---
>
> fs/nfs/nfs4proc.c | 1 +
> fs/nfs/nfs4xdr.c | 26 ++++++++++++++++++++++++++
> include/linux/nfs_fs_sb.h | 3 +++
> include/linux/nfs_xdr.h | 1 +
> 4 files changed, 31 insertions(+), 0 deletions(-)
>
<snip>
> index 6532d7b..f07d966 100644
> --- a/include/linux/nfs_fs_sb.h
> +++ b/include/linux/nfs_fs_sb.h
> @@ -144,6 +144,9 @@ struct nfs_server {
> u32 acl_bitmask; /* V4 bitmask representing the ACEs
> that are supported on this
> filesystem */
> + u32 fh_expire_type; /* V4 bitmask representing file
> + handle volatility type for
> + this filesystem */
> struct pnfs_layoutdriver_type *pnfs_curr_ld; /* Active layout driver */
> struct rpc_wait_queue roc_rpcwaitq;
> void *pnfs_ld_data; /* per mount point data */
> diff --git a/include/linux/nfs_xdr.h b/include/linux/nfs_xdr.h
> index d609631..ff74d94 100644
> --- a/include/linux/nfs_xdr.h
> +++ b/include/linux/nfs_xdr.h
> @@ -973,6 +973,7 @@ struct nfs4_server_caps_res {
> u32 acl_bitmask;
> u32 has_links;
> u32 has_symlinks;
> + u32 fh_expire_type;
> struct nfs4_sequence_res seq_res;
> };
I had a similar patch in my volatile file handle tree,
(http://www.spinics.net/lists/linux-nfs/msg26069.html) but in my commit I used
fs_info instead of server caps. If I remember the spec correctly, it says that
the attribute is set per file system, that's why I put it in fs_info. I'm just
curious why you used server caps, not that it really makes a difference.
-Matt Treinish
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
