2013年11月15日星期五

SyNS'13 session 2: Storage

Storage Class Memory Needs Flexible Interfaces
Sanketh Nalli, Michael Swift

Different SCM:
1. Phase-Change Memory (PCM) -- reads fast as memory writes fast as flash
2. Spin-transfer torque MRAM
3. Flash-backed DRAM
4. ???

Now it relies on FIle system because:
1. global naming
2. protected sharing (deletee open files, etc.)
3. Crash Consistency
Some use direct mapping for data, but go through FS for metadata

But name-space operations matter!

Causes of problems:
1. Trapping into the OS --- everything is a file
2. Fixed interface exposed by the file system

What if POSIX FS for latency app, and PROXY FS for new app?

Solution: Aerie (A user-mode file system which provides flexible interfaces)

SCM Manager: allocation, protection, addressing
LibFS: namespace implementation
Trusted Service: integrity and consistency

Two file system implemented, one POSIX-like, one Key-Value store like



Fault Isolation and QUick Recovery in Isolation File Systems
Lanyue Lu, Remzi

A small fault can cause global failure -- all files on a file system share a single fault domain.

Solution:
A new abstraction of fault domains. (Isolation FS)

File system failure behaviour study:
1. What global failurs are used?
     Read-only, crash. Over 67% of global failures will crash the file system
2. Causes of global failures??
     Metadata corruption, I/O failure, or software bug (null poiter, say). All global failures are caused by system states, not user data.

Current FS abstractions:
File and directory, namespace, partition(panic still take down whole OS, and inefficient)

Isolation File Systems:
  File Pod: an abstract partition, which contains a group of files and "related metadata"
   1. Isolate metadata for each file pod
   2. Covert global failure to local falures.
Impletation on ext3:
   1. A file pod contains multiple block groups. A pod id is inserted for each group descriptor. 
   2. Deframnation for groups.
   3. Journal isolation: virtual journal contains updates only from one pod

Q: Is there a case where you want global failures?


Optimistic Crash Consistency:
Vijay, Remzi

FIle system conflate ordering and durability, which makes consistency expensive.
They provide ofsync() which priovides ordering without durability, which leads to a high performance file system which provides strong consistency as ext4, just not much timeless. 

Techniques:
1. Disk notification when a block hits surface
2. transaction checksum to detect re-ordering in journal blocks
3. Some other techniques

Insights:
More and more layers between app and storage. Need interfaces that provides freedom for each layer but still have correctness.



没有评论:

发表评论