# Presentation: 266175

## Presentation at SciDAC face-to-face

January 2005

Ron A. Oldfield
Sandia National Laboratories 

**January 2005**
**Ron A. Oldfield**
**Sandia National Laboratories **

**The Lightweight File System**

## The Lightweight File System Project

**Participants:**
**SNL: Ward, Oldfield, Riesen, Lawry**
**UNM: Maccabe, Arunagiri**
**Motivation**
**Risk-mitigation for Red Storm PFS (Lustre)**
**Vehicle for parallel I/O research**
**Design Goals**
**Lightweight design**
**only critical I/O functionality (direct access to storage, security)**
**special functionality implemented in I/O libraries (above LWFS)**
**Scalable**
**expect clients with tens-to-hundreds of thousands of processes**
**I/O system should not hinder scalability of the application **
**Secure**
**authentication and authorization**
**fine-grained access controls with revocation**

***An experimental object-based storage system***
***(funded by Sandia’s CS research foundation)***

## Key features of LWFS

**Initial focus is on “secure storage architecture” (not a file system)**
**Policy  vs mechanism**
**Separate policy decisions from policy enforcement**
**Metadata servers and storage servers cooperate for policy consistency**
**Access-control**
**capability-based **
**immediate revocation**
**automatic refresh **
**fine-grained operation control**
**Containers for related objects**
**the unit for access control (no control for byte, object, or block access)**
**Every object is in a container**
**LWFS knows nothing about the structure of container**
**We have backwards pointers (not forwards)**

## What LWFS does not do

**naming (e.g, metadata)**
**data synchronization**
**data consistency**
**caching**
**prefetching**
**quota enforcement**
**data distribution**

## Basic LWFS Architecture

**Security model (Authentication and Authorization)**
**Separation of policy from mechanism**
**Scalable**
**No connection-based mechanisms (e.g., Kerberos)**
**Capabilities for access control (well... not quite)**
**not independently verifiable**
**Similar to the NASD access credential**
**Coarse-grained access control (*****containers*****)**
**Storage service**
**object-based**
**enforcement of access control policies**

## Security Assumptions and Requirements

**We assume a trusted transport mechanism**
**prevents replay attacks, man-in-the-middle attacks, and eavesdropping**
**provides network integrity**
***We do not need to provide encryption***
**Authentication**
**Use existing mechanisms (e.g., Kerberos, GSS-API)**
**Scalable (no connection-based schemes)**
**Authorization**
**Coarse grained access controls (at the container level)**
**Capabilities for scalability**
**“****Immediate” revocation of capabilities**
**Integrity**
**Make sure users cannot modify capabilities**

## Understanding the Scalability Requirements

**Prohibit ops with *****O(n)***** communications**
**Prohibit data structures of size *****O(n)***
**Limit ops with *****O(m)***** comms to rare events**

**The I/O system should not hinder scalability of application**

## Motivating the “Open-Architecture” Model

**Application-specific APIs**
**MPI-IO**
**HDF5, PnetCDF**
**ChemIO, SalvoIO**
**Application control of policies**
**Caching and prefetching**
**Data distribution**
**Synchronization**

***Applications should choose nearly all features of the I/O system***

**application**

**LWFS**

- access to datasets,
- app-specific APIs,
- caching, prefetching

**high-level**
**I/O lib**

- acesss to (parallel) files,
- reliability, data distribution,
- consistency, synchronization

- access to bytes (in objects),
- metadata management,
- security

## Status

**APIs defined **
**Storage service**
**Authentication and Authorization**
**Naming service**
**Transactions (Locks and Journals)**
**Prototype implementations**
**Storage service**
**Authorization service**
**Naming service (in progress)**

## Current and Future Work

***Vehicle for parallel I/O research***
**Scalable metadata**
**Application-specific I/O libs and file systems**
**data distribution, data consistency, caching, prefetching to match access patterns**
**mobile app/lib code (e.g., active disk)**
**Lock-free synchronization schemes**
**Lightweight database (using LWFS)**
***Framework for developing production-level parallel I/O systems***