PNFS server projects
From Linux NFS
(→spNFS) |
(→block-based projects) |
||
| (5 intermediate revisions not shown) | |||
| Line 9: | Line 9: | ||
Stores backend data in ordinary local disk filesystems (like ext3), with a hybrid user/kernel (fuse-like) design, and IO to the metadata server. ([http://www.connectathon.org/talks08/dmuntz-spnfs-cthon08.pdf 2008 connectathon presentation].) | Stores backend data in ordinary local disk filesystems (like ext3), with a hybrid user/kernel (fuse-like) design, and IO to the metadata server. ([http://www.connectathon.org/talks08/dmuntz-spnfs-cthon08.pdf 2008 connectathon presentation].) | ||
| - | Currently | + | Currently unmaintained. Would probably need a redesign or two. |
==== gfs2 ==== | ==== gfs2 ==== | ||
| Line 23: | Line 23: | ||
=== block-based projects === | === block-based projects === | ||
| - | + | Rick McNeal, LSI Logic, released: | |
| + | http://git.linux-nfs.org/?p=rmcneal/linux-pnfs.git;a=summary | ||
| + | and | ||
| + | http://git.linux-nfs.org/?p=rmcneal/ctl.git;a=summary | ||
| + | |||
| + | Implementing a block-based pNFS MDS based on the spnfs infrastructure. | ||
| + | The lpan is to merge this into the pnfs tree once we have some minimal | ||
| + | documentation describing how to set up the server. | ||
| + | |||
| + | Rick McNeal said: "I guess I should chime in and talk about the block layout work. The pNFS server can run on any file system which is willing to provide an inode to block mapping function[1]. Since the clients are expected to have the same block level access to the storage as the server there's no extra load added to the storage devices. | ||
| + | |||
| + | [1] There's a couple of other pieces, but at the heart of the matter is the need to map an inode to devid/extent_list" | ||
| + | |||
| + | Unmaintained. Appears to be still very much a prototype. | ||
=== objects-based projects === | === objects-based projects === | ||
| Line 30: | Line 43: | ||
An object-based filesystem intended in part to be used as a pNFS backend. Exofs is currently merged, and is nfs-exportable. Intend to support mirroring and raid0 across multiple OSD's. Unsure of current status. | An object-based filesystem intended in part to be used as a pNFS backend. Exofs is currently merged, and is nfs-exportable. Intend to support mirroring and raid0 across multiple OSD's. Unsure of current status. | ||
| + | |||
| + | Benny Halevy said Feb. 15 2009: "Our plan for the Objects back-end is to export exofs (EXtended Objects FileSystem) over pNFS. Exofs is kernel-resident which uses OSD for persistent storage. Currently it supports a single OSD and support for multiple OSDs is on the roadmap. With regards to clustering, the pNFS over exofs architecture is centralized so that there is a single MDS running the single instance of the filesystem code and there are multiple OSDs with which both the filesystem manager and the clients are talking." | ||
Latest revision as of 18:33, 12 October 2010
This is a list of projects that we know of that could be candidates for inclusion in major linux distributions. That means they will need to run on Linux, be licensed as free/open source software, and have the quality, performance, and usefulness necessary to convince upstream projects (such as the linux kernel) that they're worth the additional code.
For each project we'd like to know how much remains to do to meet those requirements.
Contents |
files-based projects
spNFS
Stores backend data in ordinary local disk filesystems (like ext3), with a hybrid user/kernel (fuse-like) design, and IO to the metadata server. (2008 connectathon presentation.)
Currently unmaintained. Would probably need a redesign or two.
gfs2
Files-based server using gfs2 to share data between metadata server and data servers.
Initial prototype exists. Has passed some simple tests. Known to cheat on the protocol somewhat (based on early 4.1 code, and doesn't enforce stateid's on the data server yet). Crashes have been reported in use. Nothing known about performance yet.
ocfs2
None exists now. However, it appears that a simple pNFS implementation is possible using only userland parts of the cluster software (with no or minimal modifications to kernel filesystem code). So any work done on gfs2 should also apply to ocfs2 with minimal effort (since they share userland infrastructure).
block-based projects
Rick McNeal, LSI Logic, released: http://git.linux-nfs.org/?p=rmcneal/linux-pnfs.git;a=summary and http://git.linux-nfs.org/?p=rmcneal/ctl.git;a=summary
Implementing a block-based pNFS MDS based on the spnfs infrastructure. The lpan is to merge this into the pnfs tree once we have some minimal documentation describing how to set up the server.
Rick McNeal said: "I guess I should chime in and talk about the block layout work. The pNFS server can run on any file system which is willing to provide an inode to block mapping function[1]. Since the clients are expected to have the same block level access to the storage as the server there's no extra load added to the storage devices.
[1] There's a couple of other pieces, but at the heart of the matter is the need to map an inode to devid/extent_list"
Unmaintained. Appears to be still very much a prototype.
objects-based projects
exofs
An object-based filesystem intended in part to be used as a pNFS backend. Exofs is currently merged, and is nfs-exportable. Intend to support mirroring and raid0 across multiple OSD's. Unsure of current status.
Benny Halevy said Feb. 15 2009: "Our plan for the Objects back-end is to export exofs (EXtended Objects FileSystem) over pNFS. Exofs is kernel-resident which uses OSD for persistent storage. Currently it supports a single OSD and support for multiple OSDs is on the roadmap. With regards to clustering, the pNFS over exofs architecture is centralized so that there is a single MDS running the single instance of the filesystem code and there are multiple OSDs with which both the filesystem manager and the clients are talking."
