Parallel Virtual File System

"},"screenshot":{"wt":"<!-- [[File:]] -->"},"caption":{"wt":""},"collapsible":{"wt":""},"author":{"wt":"[[Clemson University]], [[Argonne National Laboratory]], [[Ohio Supercomputer Center]]"},"developer":{"wt":"Walt Ligon, Rob Ross, Phil Carns, Pete Wyckoff, Neil Miller, Rob Latham, Sam Lang, Brad Settlemyer"},"released":{"wt":"2003 <!-- {{Start date|YYYY|MM|DD}} -->"},"discontinued":{"wt":""},"latest release version":{"wt":"2.8.2"},"latest release date":{"wt":"{{Start date and age|2010|01|01}}"},"latest preview version":{"wt":""},"latest preview date":{"wt":"<!-- {{Start date and age|YYYY|MM|DD}} -->"},"programming language":{"wt":"[[C (programming language)|C]]"},"operating system":{"wt":"[[Linux kernel]]"},"platform":{"wt":""},"size":{"wt":""},"language":{"wt":""},"genre":{"wt":""},"license":{"wt":"[[GNU Lesser General Public License|LGPL]]"},"website":{"wt":"{{URL|https://web.archive.org/web/20160701052501/http://www.pvfs.org/}}"}},"i":0}}]}'>

Parallel Virtual File System
Original authors	Clemson University, Argonne National Laboratory, Ohio Supercomputer Center
Developers	Walt Ligon, Rob Ross, Phil Carns, Pete Wyckoff, Neil Miller, Rob Latham, Sam Lang, Brad Settlemyer
Release	2003
icon<span typeof=\"mw:Entity\" id=\"mwcg\">]</span>","txt":"[icon]"}]]}'>

PVFS consists of 4 main components and a number of utility programs. The components are the PVFS2-server, the pvfslib, the PVFS-client-core, and the PVFS kernel module. Utilities include the karma management tool, utilities (e.g., pvfs-ping, pvfs-ls, pvfs-cp, etc.) that all operate directly on the file system without using the kernel module (primarily for maintenance and testing). Another key design point is the PVFS protocol which describes the messages passed between client and server, though this is not strictly a component.

The PVFS server runs as a process on a node designated as an I/O node. I/O nodes are often dedicated nodes but can be regular nodes that run application tasks as well. The PVFS server usually runs as root, but can be run as a user if preferred. Each server can manage multiple distinct file systems and is designated to run as a metadata server, data server, or both. All configuration is controlled by a configuration file specified on the command line, and all servers managing a given file system use the same configuration file. The server receives requests over the network, carries out the request which may involve disk I/O and responds back to the original requester. Requests normally come from client nodes running application tasks but can come from other servers. The server is composed of the request processor, the job layer, Trove, BMI, and flow layers.

The request processor consists of the server process' main loop and a number of state machines. State machines are based on a simple language developed for PVFS that manage concurrency within the server and client. A state machine consists of a number of states, each of which either runs a C state action function or calls a nested (subroutine) state machine. In either case return codes select which state to go to next. State action functions typically submit a job via the job layer which performs some kind of I/O via Trove or BMI. Jobs are non-blocking, so that once a job is issued the state machine's execution is deferred so that another state machine can run servicing another request. When Jobs are completed the main loop restarts the associated state machine. The request processor has state machines for each of the various request types defined in the PVFS request protocol plus a number of nested state machines used internally. The state machine architecture makes it relatively easy to add new requests to the server in order to add features or optimize for specific situations.

The Job layer provides a common interface for submitting Trove, BMI, and flow jobs and reporting their completion. It also implements the request scheduler as a non-blocking job that records what kind of requests are in progress on which objects and prevents consistency errors due to simultaneously operating on the same file data.

Trove manages I/O to the objects stored on the local server. Trove operates on collections of data spaces. A collection has its own independent handle space and is used to implement distinct PVFS file systems, A data space is a PVFS object and has its own unique (within the collection) handle and is stored on one server. Handles are mapped to servers through a table in the configuration file. A data space consists of two parts: a bytestream, and a set of key/value pairs. A bytestream is sequence of bytes of indeterminate length and is used to store file data, typically in a file on the local file system. Key/value pairs are used to store metadata, attributes, and directory entries. Trove has a well defined interface and can be implemented in various ways. To date the only implementation has been the Trove-dbfs implementation that stores bytestreams in files and key/value pairs in a Berkeley DB database. Trove operations are non-blocking, the API provides post functions to read or write the various components and functions to check or wait for completion.

• Free and open-source software portal

• List of file systems, the distributed parallel file system section

---

View original on Wikipedia | Back | FazBrowse Home