From b27df0deaa1baaaa80c397499332100b027503f6 Mon Sep 17 00:00:00 2001 From: Thiago da Silva Date: Thu, 28 Aug 2014 14:01:37 -0400 Subject: [PATCH] update the README file changing the README file to clarify swift-on-file operations and update with latest code changes Signed-off-by: Thiago da Silva --- README.md | 78 ++++++++++++++++++++++++++++--------------------------- 1 file changed, 40 insertions(+), 38 deletions(-) diff --git a/README.md b/README.md index ba19d51..f0320f5 100644 --- a/README.md +++ b/README.md @@ -1,52 +1,55 @@ [![Build Status](https://travis-ci.org/swiftonfile/swiftonfile.svg?branch=master)](https://travis-ci.org/swiftonfile/swiftonfile) # Swift-on-File -Swift-on-File, formerly called Gluster-Swift, is a Swift Object Server -implementation that enables objects created using the Swift API to be accessed -as files on a Posix filesystem. +Swift-on-File is a Swift Object Server implementation that enables users to +access the same data, both as an object and as a file. Data can be stored and +retrieved through Swift's REST interface or as files from NAS interfaces +including native GlusterFS, NFS and CIFS. + +Swift-on-File is to be deployed as a Swift [storage policy](http://docs.openstack.org/developer/swift/overview_policies.html), +which provides the advantages of being able to extend an existing Swift cluster +and also migrating data to and from policies with different storage backends. The main difference from the default Swift Object Server is that Swift-on-File -stores objects following the same path hierarchy as that object's URL. -On a vanilla openstack swift the object server will store the object following -the mapping given by the Ring and its final storage location and filename are -unknown to the user. In the case of Sof, the object will be stored in the -configured filesystem volume with the same directory structure as the object's -URL. +stores objects following the same path hierarchy as the object's URL. In contrast, +the default Swift implementation stores the object following the mapping given +by the Ring, and its final file path is unkown to the user. -For example, an object with URL: https://swift.example.com/v1/acc/cont/obj, -would be stored in the following way: -* Swift: /mnt/sdb1/2/node/sdb2/objects/981/f79/f566bd022b9285b05e665fd7b843bf79/1401254393.89313.data -* SoF: /mnt/gluster-vol/acc/cont/obj +For example, an object with URL: `https://swift.example.com/v1/acct/cont/obj`, +would be stored the following way by the two systems: +* Swift: `/mnt/sdb1/2/node/sdb2/objects/981/f79/f566bd022b9285b05e665fd7b843bf79/1401254393.89313.data` +* SoF: `/mnt/swiftonfile/acct/cont/obj` -## Roadmap -Swift-On-File is in a transition period. The project was recently renamed from -Gluster-Swift to Swift-on-File to better represent its nature of a Swift backend -that supports multiple Posix Filesystems, not just GlusterFS. It is also -transitioning to become a Swift Storage Policy. While Gluster-Swift had to be -deployed as its own cluster, SoF can be deployed as a storage policy on an -existing Swift cluster. This is a tremendous change to the project as it opens -up new possibilities of how SoF can be used, such as, enabling the ability to -consume and migrate existing file storage (e.g., NFS) on a swift cluster. +## Use cases +Swift-on-File can be especially useful in cases where access over multiple +protocols is desired. For example, imagine a deployment where video files +are uploaded as objects over Swift's REST interface and a legacy video transcoding +software access those videos as files. -Our last stable [release](https://github.com/swiftonfile/swiftonfile/releases) -was targetting the Swift Icehouse release. This was the last release of -Gluster-Swift. The next release will target Juno, with support for storage -policies. +Another use case is where users might need to migrate data from an existing file +storage systems to a Swift cluster. -Besides the work to support Storage Policies we also plan on adding support -for other Filesystems (e.g., NFS) and also for enabling the access of objects -through multiple protocols. +## Limitations and Future plans +Swift-On-File currently works only with Filesystems with extended attributes +support. It is also recommended that these Filesystems provide data durability +as Swift-On-File should not use Swift's replication mechanisms. + +GlusterFS is a good example of a Filesystem that works well with Swift-on-File, +GlusterFS provides a posix interface, global namespace, scalability, data +replication and support for extended attributes. + +Currently, files added over a NAS protocol (e.g., native GlusterFS), do not show +up in container listings, still those files would be accessible over Swift's REST +interface with a GET request. We are working to provide a solution to this limitation. + +Future plans includes adding support for Filesystems without extended attributes, +which should extend the ability to migrate data for legacy storage systems. -To learn more about the history of Gluster-Swift and how Swift-On-File came -to be, you can watch this presentation given at the Atlanta Openstack Summit: -[Breaking the Mold with Openstack Swift and GlusterFS](http://youtu.be/pSWdzjA8WuA). +## Get involved: +To learn more about Swift-On-File, you can watch this presentation given at +the Atlanta Openstack Summit: [Breaking the Mold with Openstack Swift and GlusterFS](http://youtu.be/pSWdzjA8WuA). Presentation slides can be found [here](http://lpabon.github.io/openstack-summit-2014). -## Supported Filesystems: -* XFS -* GlusterFS - -## Get involved: Join us in contributing to the project. Feel free to file bugs, help with documentation or work directly on the code. You can communicate with us using GitHub [issues](https://github.com/swiftonfile/swiftonfile/issues) or find us in the #swiftonfile channel on Freenode. @@ -54,4 +57,3 @@ us in the #swiftonfile channel on Freenode. # Guides to get started: 1. [Quick Start Guide with XFS/GlusterFS](doc/markdown/quick_start_guide.md) 1. [Developer Guide](doc/markdown/dev_guide.md) -