From Linux NFS

3 December 2012	DRAFT	bjschuma@netapp.com

Contents 1 Overview 2 Related Documents 3 Dependencies 3.1 This design needs the following from others: 3.2 Assumptions 4 Design 5 Feature Interaction Dependencies and Impacts 6 Performance 7 Scalability 8 Open Issues 9 Approvals 9.1 Approvers 9.2 Reviewers

Overview

Peer-to-peer pNFS is designed to solve the "boot storm" problem that happens when several clients in a cluster boot and attempt to read the same set of files from a single NFS server all at the same time. This could overload the server's bandwidth, slowing down operations on most client machines. The idea behind p2p NFS is to allow clients to act as an adhoc read-only pNFS data server that serves files out of their data cache. This should spread out network usage across all machines, rather than focusing all activity on a single node. Server and desired DS machines will need to be modified but any pNFS-enabled client already has the code required to read from adhoc DSs.

Related Documents

• draft-myklebust-nfsv4-pnfs-backend-protocol-01.txt
• RFC 5661

Dependencies

This design needs the following from others:

Item	Description of Dependency or Issue	Affected Group	Contact
1	Linux pNFS server development code	Bryan Schumaker	Benny Halevy
2	pNFS nfs utils needs to be installed on the NFSD server so it can export a filesystem over pNFS.	Bryan Schumaker	Benny Halevy

Assumptions

• Enable the following .config options for the pNFS client and pNFS ds machines:
  • CONFIG_NFS_V4_1
  • CONFIG_PNFS_FILE_LAYOUT
• Enable the following .config option for the pNFS ds machine:
  • CONFIG_NFS_P2P
• Enable the following .config options for the pNFS server and pNFS ds machines:
  • CONFIG_PNFSD
  • CONFIG_PNFSD_LOCAL_EXPORT
  • CONFIG_PNFSD_P2P
• Install pnfs-nfs-utils on the pNFS server
• Add "pnfs" to the export options of a local filesystem on the pNFS server
• pNFS DS should have nfsd running, but does not need to edit /etc/exports to share files
• pnfsd needs to add "pnfs" export option to /etc/exports
• pnfsd also needs to have "fsid=0" as an export option, otherwise the path walking code will trigger an early UNREGISTER_DS.

Design

DESCRIBE YOUR DESIGN IN THIS SECTION

This section is typically the largest section. Since designs are highly specific, the template cannot provide much in the way of guidelines here. Information which is relevant to the sections below should not be discussed here.

This is the main place where customizing the template for each particular team can really pay off. Teams are encouraged to add a section for the design considerations their own particular area needs to address.

The Design specification describes how the functionality is implemented. Intended readers are:

• Engineering (current and future)
• QA; given this spec, QA should understand the design enough to be able to create white-box type tests for the various parts.

• Overall design
  This document should describe:
  • How it works, in detail.
  • Module breakdown
  • Major data paths through the code. (Referring to the use cases might be useful here)
  • Process structure.
  • Major data structures.
  • Concurrency, parallelism, and mutual exclusion.
  • Class hierarchy, if your design uses object-oriented notions of inheritance and polymorphism. This applies to, but is not limited to, development done in object-oriented languages such as C++ and Java.
  • A UML diagram may be the easiest and most precise way of describing the relationship between the various abstractions supported by your design.
  • Any state machines.
  • Resources used, how they’re controlled, what we do when we run out, recovery steps

• Upgrade/revert
  • Describe how upgrade and revert work.

• Install/uninstall
  • Describe how the product is installed and uninstalled.

• Versioning/compatibility
  • Describe how the versioning checks are implemented.
  • If wire- or disk-layout is important, discuss tools (like IDL’s) used to achieve that.

• Online documentation
  • Describe implementations of documentation of any form (for example, tools which process commentary and create other documents)

Feature Interaction Dependencies and Impacts

• nfsd <-> nfs
  • The machine acting as a pNFS DS needs to be running both the nfs server and the nfs client.

Performance

• Keep a per-file LRU list of clients that currently have the file cached to avoid redirecting all p2p activity to the same client for that file.

Scalability

The hope is that p2p NFS scales to hundreds and thousands of clients better than straight pnfs does. This can be tested by comparing read times for files of varying sizes both with and without p2p enabled. A handful of DSs and a large number of clients should be used to get a feel for how this would work in a data center.

Open Issues

Item	Date	Name	Issue	Resolution	Date Resolved
1	12/11/2012	Bryan	Client needs to mount server with the public filehandle, otherwise the path walking code will trigger an early UNREGISTER_DS.	[NONE]	[NONE]

Approvals

Approvers

Name	Role	Target Approval Date	Approval Date
Trond Myklebust	NFS Client Maintainer	Date	Date

Reviewers

Name	Role	Target Approval Date	Approval Date
Jeffrey Heller	Bryan's Manager	Date	Date