ENERGY-EFFICIENCY%20AND%20STORAGE%20FLEXIBILITY%20IN%20THE%20BLUE%20FILE%20SYSTEM - PowerPoint PPT Presentation

About This Presentation
Title:

ENERGY-EFFICIENCY%20AND%20STORAGE%20FLEXIBILITY%20IN%20THE%20BLUE%20FILE%20SYSTEM

Description:

ENERGY-EFFICIENCY AND STORAGE FLEXIBILITY IN THE BLUE FILE SYSTEM E. B. Nightingale and J. Flinn University of Michigan Energy efficiency Different benchmark run with ... – PowerPoint PPT presentation

Number of Views:109
Avg rating:3.0/5.0
Slides: 38
Provided by: Jehan108
Learn more at: https://www2.cs.uh.edu
Category:

less

Transcript and Presenter's Notes

Title: ENERGY-EFFICIENCY%20AND%20STORAGE%20FLEXIBILITY%20IN%20THE%20BLUE%20FILE%20SYSTEM


1
ENERGY-EFFICIENCY AND STORAGE FLEXIBILITYIN THE
BLUE FILE SYSTEM
  • E. B. Nightingale and J. Flinn
  • University of Michigan

2
Key ideas
  • Reduce power consumption of portable devices
  • Two big culprits
  • Disk drive
  • Wireless
  • Integrate flash drives

3
Dynamic storage hierarchy
  • We should power down drives when they are idle
  • But this causes powering up delays
  • To mask these delays introduce a dynamic storage
    hierarchy
  • Includes flash drives and remote server
  • Takes into consideration state of local disk
    drive

4
Examples
  • Disk is powered up
  • Disk is powered down

The storage hierarchy depends on the status of
the hard disk.
5
Incorporating flash drives
  • To satisfy read requests, Blue FS looks first in
    the flash drive
  • Implies
  • A write all/read any policy
  • Treating flash drives as caches
  • Need a quick way to query flash drive contents

6
More on caches
  • Unit of caching is block
  • Can cache some blocks of a file but not all
  • Must maintain information on validity and
    currency of each cached block
  • See details in paper

7
Write to all/read any
  • All writes are propagated to all devices

Server
Disk
8
Advantages
  • Write all allows read any
  • Future power savings
  • Requires efficient writes
  • Propagates all updates to the server
  • Unless in disconnected mode

9
Aggregating writes (I)
  • Blue FS maintains one write queue per device

Server
Disk
10
Aggregating writes (II)
  • When it writes to a device, it flushes the whole
    queue

Server
Disk
11
Aggregating writes (III)
  • After the writes, each queue is empty

Server
Disk
12
More on device queues
  • Device queues share among themselves all common
    blocks
  • Save space
  • Blocks in device queues can be accessed through a
    hashing scheme
  • Always access most recent version of a block even
    when it is not yet saved on any device

13
Why?
  • Makes a lot of sense for disk drive and remote
    server
  • Power up disk, do a few updates, then power down
  • Power up wireless connection, send a few updates
    then power down
  • Delaying updates allows BlueFS to coalesce
    multiple updates to the same block

14
Using flash drives as caches
  • Small flash drives cannot contain whole contents
    of file system
  • Especially true in 2004!
  • Must have a fast way to find whether a file is
    cached or not
  • Enode

15
E-node
  • Captures all the information Blue FS has about
    the validity of an object
  • E-nodes are
  • Hashed by file id
  • Stored in an e-node cache managed by LRU
    replacement policy
  • Default size is one MB

16
Cache consistency
  • Uses
  • Optimistic replica control (Coda)
  • Callbacks (AFS)
  • Changes
  • Blue FS maintains callbacks on a per-device
    basis, instead of on a per-client basis
  • Server queues invalidation messages when a device
    is disconnected.

17
Optimistic replication
Updated for Fall 2012
  • Optimistic replication control protocols allow
    access in disconnected mode
  • Tolerate temporary inconsistencies
  • Promise to detect them later
  • Provide much higher data availability

Optimistic replication control putsdata
availability above data consistency
18
Callbacks (I)
Updated for Fall 2012
  • When a client opens a file for the first time,
    server promises to notify it whenever it receives
    a new version of the file from any other client
  • Promise is called a callback
  • Relieves the server from having to answer a call
    from the client every time the file is opened
  • Significant reduction of server workload

19
If machines could talk (I)
99 of these requests are useless!
I should contact the server each time I open any
file
Server
Client
20
If machines could talk (II)
You do not need to call me I promise to call you
back if anyone has modified the file
??
Server
Client
21
If machines could talk (III)
What if I do not receive your callback?
Though luck!
Server
Client
22
Callbacks (II)
  • Callbacks can be lost!
  • Client will call the server every tau minutes to
    check whether it received all callbacks it should
    have received
  • Cached copy is only guaranteed to reflect the
    state of the server copy up to tau minutes before
    the time the client opened the file for the last
    time

23
If machines could talk (IV)
Sure as long as you do not do it too frequently
I will contact you from time to time to check for
lost callbacks
Server
Client
24
Disconnected mode
  • Like Coda, Blue FS works in disconnected mode
  • User has access to all files cached
  • On local disk drive
  • On flash drive if any
  • Can even specify that some files must always be
    cached
  • Affinity

25
Disconnected mode (II)
  • When a device is disconnected, server queues all
    callbacks that could not be delivered to the
    device
  • Speeds up reintegration
  • If inconsistencies are discovered at reconnection
    time, will run a resynchronization process

26
Accessing large files
  • When disk is powered down, Blue FS get first file
    blocks from remote server

27
Deciding which device to use
  • If decisions are made for each individual access
  • Will never activate a disk thats powered down
  • Blue FS uses ghost hints
  • Measure penalty for not using a disk that is
    powered down for a given access
  • When sum of ghosts hints exceeds the cost of
    powering up the disk, disk is powered up

28
Blue FS architecture (II)
Updated for Fall 2012

29
Blue FS architecture (I)
  • Most of Blue FS functionality is implemented in a
    user-level process
  • Wolverine
  • Kernel-resident part of Blue FS intercepts I/O
    calls that have to be forwarded to Wolverine

30
Blue FS architecture (II)
31
Performance
  • Will use a standard benchmark
  • Andrews/AFS benchmark
  • Will compare interactive delays andpower
    consumption against
  • NFS
  • Coda with synchronous server updates (Coda)
  • Coda with asynchronous server updates(Coda WD)

32
Interactive delay
6000.0
  • Ten times faster than NFS, 16 faster than Coda WD

33
Adding a 16MB flash drive
  • Assumes that cache is fully loaded
  • 48 shorter interactive delay 48, 25 less energy

34
Energy efficiency
  • Different benchmark run with half-full cache
  • 76 shorter interactive delay, 55 less energy
    than Coda

35
Adding a 16MB flash drive
  • Assumes that cache is fully loaded
  • 48 shorter interactive delay, 25 less energy

36
Discussion
  • Comparison with NFS is unfair
  • NFS was designed for LANs, not WANs!
  • Comparison with Coda is fair but
  • Coda did not incorporate flash drives
  • Did not exist then!
  • Coda did not try to minimize power consumption
  • Portable devices did not exist then!

37
Conclusion
  • Blue FS updates Coda by taking into consideration
    the arrival of
  • Wireless networks (near ubiquitous access)
  • Portable devices (limited autonomy)
  • Flash drives
  • Retains Coda features such as optimistic
    replication, callbacks and disconnected mode
    operation
Write a Comment
User Comments (0)
About PowerShow.com