Towards Automatic File Systems

By Kanchan Damle

Course InstructorProf. Remzi Arpaci-Dusseau

CS 736

Spring 2008

AGENDA• Lot of Questions

• Implementation.– Basic File System Design.– FUSE

• Some Measures.– Performance of File System.

• Conclusions

• Questions?

The usual questions for any new idea !!

• What?

– User :Specifies

– Implementer: Will be Done!

• Why?

– User knows his needs better

– Flexibility

– Optimum Resource Usage

• How?

– Let the user specify

– Just redirect the system calls

Implementation Details

• Say user wants : “Simple FS”

(I picked another ,“S”- SFS)– 1 superblock

-no redundancy like FFS– Inode and Data Bitmaps

-no problems of free-list .– Limit to 100 files.– User not sure of how he will access the data..

Other Details

• Max Number of Open Files: 25• Max File Size : 15K• Some reserved blocks.• Maximum Filename length = 16 • Maximum Pathname length = 256• Root Exists !(Inode #2)• Persistent Storage on File:

– Raw device – File on existing file system.

Implementation Details

0 1 2 3 4 5-39

SUPER BLOCK

INODE-BITMAP

DATA-BLOCK BITMAP SECTORS 5-39 INODES

METADATA STRUCTURES

***Data blocks follow 40 onwards

Implementation Details Why FUSE?

• User level FS implementation done

• But how can we have system level calls directed to implemented FS?

• Need ? -perhaps Uniformity, hassle to remember the new calls..

• Solution : Indirection!

• FUSE can help

FUSE unveiled!

• What is FUSE?

• A framework: Redirects FS calls to (User level ) Simple FS API

• Has two modules + Mount Utility

– User Library : Interfaces with the Simple FS API

– Kernel Module : Binds to VFS, Calls FUSE Library

Basic Call Flow..

Interface Details

Kernel Module

FUSE Library

Simple FS

[6]

[1]

[0] [2]

[3] [4]

[5]

User Space

Kernel Space

Blocking Read Call

[0] Blocking read call on kernel module

[1] Request from VFS

[2] Unblocks the thread and sends request

[3] Fuse Library invokes respective Simple FS Module

[4] Module returns with requested data.

[5] Transfer data to kernel module

[6] Transfer data to VFS

Internal Details

• VFS System Call Map – unlink() -> sys_unlink

• Fuse kernel call transfer– sys_unlink -> fuse_read_device

• Request Processing – User Level FS call invoked

• Blocking Calls : Queues Used– Pending, processing, etc

Cost-Benefit …

• Benefits :– Flexibility

– Not tied to any particular OS– Avoid Kernel recompilation– Non-privileged mounts possible– Simplicity : Coding in user space is simpler

Cost :

More overhead: More user and kernel switching

Performance Measures .. Simple FS

Run Number

Performance Measures .. Simple FS

Conclusions

• Good performance– Buffered writes, fewer writes

• No worry about positioning time – Uniform access time

• Flexibility– User gets what he requires

• System calls redirected hence easy to use.– Don’t remember erratic name and be uniform

• But,– Periodic FS_Sync required– What if file deleted?– Yet not secure for sensitive data

Lessons Learnt

• Reading does not imply doing.

• Simple things can be bigger hurdles!

• Planning work helps

• Give it “time” and “thought”

• Believe that you can do it!

QUESTIONS?

Thank you…