Open Stack

Greetings,

A blueprint has been submitted for an extension to enable Local File Systems to take responsibility for
certain operations, allowing generic Swift code to offload some burdens when these optional capabilities
are available.

The goal of this proposal is to allow an Object Server to take advantage of the capabilities of the ZFS
file system, but it could be applied for other enhanced file systems as well.

The blueprint is: https://blueprints.launchpad.net/swift/+spec/localfs
The etherpad description is: http://etherpad.openstack.org/YMTqYzPmZQ

This is the first of what will probably be a handful of proposals from Nexenta Systems, all with the goal
of enabling value added Object Servers.

So we should introduce ourselves.

Nexenta brings open source solutions built on ZFS to provide software-based NAS/SAN appliances. The core value of the ZFS file system is delivered in an enterprise class storage solution. We intend to bring  the value of ZFS as a local file system to Cloud Storage as well.

>From http://en.wikipedia.org/wiki/ZFS

In computing, ZFS is a combined file system and logical volume manager designed by Sun Microsystems. The features of ZFS include data integrity verification against data corruption modes (like bit rot), support for high storage capacities, integration of the concepts of filesystem and volume management,snapshots and copy-on-write clones, continuous integrity checking and automatic repair, RAID-Z and native NFSv4 ACLs. ZFS is implemented as open-source software, licensed under the Common Development and Distribution License (CDDL). The ZFS name is a trademark of Oracle.[3]



To take advantage of ZFS capabilities we will need to work with the Swift project to define how the core Swift code discovers and exploits optional capabilities.  This is a role similar to that of a graphics chip or network interface vendor working with an open source OS project. The goal is to enable enhanced functionality with interfaces that make  the enhanced functionality optional and largely vendor neutral. Other file system providers should be able to plug-in in their own solutions.

Nexenta appliances are based on open source operating system that utilizes OpenSolaris, in a near future - Illumos, kernel. This means we will end up testing that the python code is truly OS independent, and we anticipate submitting a steady but hopefully small stream of patches to fix code that was inadvertently Linux dependent. The goal will be to supply patches that make the code truly generic, and hopefully avoid just accumulating any "if linux elif illumos elif bsd ..." sequences in Swift code.

>From http://en.wikipedia.org/wiki/Illumos:

Illumos is a derivative of OS/Net (aka ON), which basically is a Solaris/OpenSolaris kernel with the bulk of the drivers, core libraries, and basic utilities. It is dependent on OS/Net, which Illumos will follow very closely while allowing to retain changes to code which might be unacceptable to upstream OpenSolaris. Illumos is aiming at 100% ABI (Application Binary Interface) compatibility with Solaris ON, focusing just on the core foundation blocks.