Extensible File System in Spring Yousef A. Khalidi, Michael N. Nelson Sun Microsystems Laboratories,

1
Extensible File System in SpringYousef A.
Khalidi, Michael N. NelsonSun Microsystems
Laboratories, Inc.SOSP93

• Lee Sang-Kwon
• 1998/5/6
• CA Lab, CS, KAIST

2
Contents

• Introduction
• Requirements
• Spring
• Spring File Stackable Architecture
• Interposing on a Per-file Basis
• Implementation
• Conclusions and Future Work

3
Introduction

• Architecture for extensible file systems
• the architecture enables extension of FS
  functionality by stacking new FSs on top of
  existing file systems
• new FS can access the existing FSs files and
  can share the same underlying fiel data in a
  cohrent manner
• in the context of Spring operating system
• Spring features
• virtual memory
• strongly-typed well-defined interfaces
• location-independent invocation mechanism
• flexible naming architecture

4
Requirements

• Leveraging existing file systems
• build new file systems from scratch or leverage
  existing file systems
• Caching
• means for caching file data and attributes
• Coherency
• keep file data and attributes coherent
• coherency policy left to implementation
• Dynamic addition of functionality
• add new functionality to a running system
• dynamically extend the functionality of files

5
Spring (1)

• The Spring Operating System
• distributed multi-threaded operating system
• object state a set of operations
  interface
• interface inheritance
• domain address space a collection of threads
• act as server of some objects and client of other
  objects
• server and client can be in the same/different
  domain
• typical Spring node runs several servers

6
Spring (2)

• Naming
• Spring allows any object to be associated with
  any name
• name binding name-to-object association
• context an object that contains a set of name
  bindings

7
Spring (3)

• Virtual Memory
• VMM(Virtual Memory Manager)
• handle mapping, sharing, caching of local memory
• depends on external pagers for accessing backing
  store and maintaining inter-machine coherency
• clients of VM system only deal with address space
  and memory object
• address space object virtual address space of a
  Spring domain
• memory object an abstraction of store(memory)
  that can be mapped into address space
• bind operation
• no paging operations
• pager page-in/out the actual contents of the
  memory objects

8
Spring (4)

• Virtual Memory (cont)
• two-way connection btw. VMM and pager
• allow data to be coherently cached by more than 1
  VMM
• pager object provides methods to page-in and
  page-out memory blocks
• cache object performs coherency actions
• there are many pager-cache object channels Fig
  2
• data conherency btw. different VMMs that are
  caching a memory object gt responsibility of the
  pager for the memory object

9
Spring File Stacking Architecture (1)

• Overview
• Spring FS stacking architecture enables the
  extension of FS functionality by adding new FS
  layers on top of existing FSs
• as long as interface of new layer conforms to
  interface of a FS, clients will view the new
  layer as a FS
• implementation vs. administrative decisions Fig
  3
• 3 components to extensible FS architecture
• stackable papger interface
• for caching data and keeping it coherent
• stackable attribute interface
• for caching file attributes and keeping
  them cohrent
• stackable FS interface
• compose FSs and arrange file name space

10
Spring File Stacking Architecture (2)

• Stackable Pager Interface
• Cache manager implements cache objects
• anybody can implement cache objects
• example Fig 4
• 2 design decisions
• keep the layers files coherent with the files
  underlying FS Fig 5, Fig 6
• use the same cached pages for the layers files
  and the files of underlying FS Fig 7

11
Spring File Stacking Architecture (3)

• Stakable File Attributes Interface
• file attributes access/modified time, file
  length, ...
• one approach to handling file attributes
  add more operations to cache/pager object
  interfaces gt problems
• we subclass

cache object pager object
fs_cache object fs_pager object
add more operations
12
Spring File Stacking Architecture (3)

• Configuring File Systems
• mechanism to construct FS layers
• interface stackable_fs_creator
• create instances of stackable FSs
• stackable_fs stackable_fs_creatorcreate()
• at boot-time or during run-time, file system
  creator for each FS type is created
• method to configure a new FS
• FS creator object is looked up
• stackable_fs dfs dfs_creator_obj-gtcreate()
• dfs-gtstackon(fs2)
• some_name_server-gtbind(ctx, dfs)

13
Interposing on a Per-File Basis

• Use the same stacking architecture to change the
  semantics of individual files(or operations)
• object interposition
• O1(type foo) can be substituted for O2(type foo)
• O1 decides on a per-operation basis whether O1/O2
• at name-resolution time
• interposer resolves the name of context
• interposer selectively intercept name resolutions

14
Implementation

• Spring operating system
• impelemented, now stable
• File system implementations
• Spring DFS(distributed FS)
• Spring SFS(storage FS)
• Spring CFS(attribute-caching FS)

15
Performance (1)

• Performance measurements
• additional overhead gt crossing interface
  boundaries
• we measured using SFS which contains 2 layers

- no significant overhead from stacking if the
layers are in the same domain - when 2 layers are
in different domains, there is a fairly
significant overhead for open operation - when
coherency layer caches, there is no overhread
from stacking - when there is no data caching,
stacking overhead is insignificant
16
Performance (2)

• Cost of operations on SunOS 4.1.3
• Spring is 2 - 7 times slower than SunOS
• Configuring stacked FS layers
• the layers can reside in the same domain
• the layers an be in different domains, but data
  and attribute caching can be used
• the bottom layers can be attached to a slow
  device such as a disk

17
Conclusions and Future Work

• Spring extensible FS architecture
• extend FS functionality by structuring FSs as a
  set of dynamically configurable layers
• keep file data and attributes coherent btw.
  layers
• provide flexibility without sacrificing
  performance
• Future work
• implementing a compression FS layer
• name caching
• efficient bulk data transfer
• extensible FS configuration tools