From owner-svn-doc-all@freebsd.org Thu May 4 03:51:14 2017 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4BDBFD5D35C; Thu, 4 May 2017 03:51:14 +0000 (UTC) (envelope-from bjk@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ECD0F1065; Thu, 4 May 2017 03:51:13 +0000 (UTC) (envelope-from bjk@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id v443pDW8036837; Thu, 4 May 2017 03:51:13 GMT (envelope-from bjk@FreeBSD.org) Received: (from bjk@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id v443pDBH036836; Thu, 4 May 2017 03:51:13 GMT (envelope-from bjk@FreeBSD.org) Message-Id: <201705040351.v443pDBH036836@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: bjk set sender to bjk@FreeBSD.org using -f From: Benjamin Kaduk Date: Thu, 4 May 2017 03:51:13 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r50229 - head/en_US.ISO8859-1/htdocs/news/status X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 03:51:14 -0000 Author: bjk Date: Thu May 4 03:51:12 2017 New Revision: 50229 URL: https://svnweb.freebsd.org/changeset/doc/50229 Log: Some corrections to the 2017Q1 pNFS entry I had mixed up the File Layout and Flex File Layout; only the latter allows NFSv3 servers to act as data servers. Also lowercase Read/Write/Data/MetaData to match the prevailing style. Discussed with: rmacklem Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2017-01-2017-03.xml Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2017-01-2017-03.xml ============================================================================== --- head/en_US.ISO8859-1/htdocs/news/status/report-2017-01-2017-03.xml Wed May 3 20:44:44 2017 (r50228) +++ head/en_US.ISO8859-1/htdocs/news/status/report-2017-01-2017-03.xml Thu May 4 03:51:12 2017 (r50229) @@ -261,20 +261,21 @@

Parallel NFS (pNFS) is an extension to the NFSv4 protocol that allows for file accesses within a single logical mount to be - performed against multiple NFS file servers, "in parallel". - Thus, a pNFS server separats the MetaData operations from the - Data operations (Read/Write/Setattr of size N), letting - existing NFSv3 servers be used for the bulk data storage - while still taking advantage of NFSv4 protocol enhancements, - among other things.

+ performed against multiple file servers, with the potential + for data access to occur in parallel. The pNFS + "layout" specifies how the division occurs, with + metadata operations occuring against the main server, and + bulk data operations (read/write/setattr/etc.) occuring via + a layout-specific scheme between the client and data + servers.

My first attempt at a pNFS server using GlusterFS was a dud. It worked, but performance was so poor that it was not usable. This attempt that I call Plan B, only uses &os;, - with one &os; server handling the MetaData operations and K - &os; servers configured to serve Data. An NFSv4.1 client + with one &os; server handling the metadata operations and K + &os; servers configured to serve data. An NFSv4.1 client that supports the pNFS File Layout will be able to - Read/Write to the Data servers directly, spreading out the + read/write to the data servers directly, spreading out the RPC load and allowing growth beyond that of what a single &os; NFS server could achieve.