energy-efficiency and storage flexibility in the blue file system e. b. nightingale and j. flinn...
TRANSCRIPT
ENERGY-EFFICIENCY AND STORAGE FLEXIBILITY
IN THE BLUE FILE SYSTEM
E. B. Nightingale and J. FlinnUniversity of Michigan
Key ideas
• Reduce power consumption of portable devices– Two big culprits
• Disk drive• Wireless
• Integrate flash drives
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
Examples
• Disk is powered up • Disk is powered down
Flash
Disk
Server
Flash
Server
Disk
The storage hierarchy depends on the status of the hard disk.
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
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
Write to all/read any
• All writes are propagated to all devices
Disk
Server
Advantages
• Write all allows read any– Future power savings
• Requires efficient writes– Propagates all updates to the server
• Unless in disconnected mode
Aggregating writes (I)
• Blue FS maintains one write queue per device
Disk
Server
Aggregating writes (II)
• When it writes to a device, it flushes the whole queue
Disk
Server
Aggregating writes (III)
• After the writes, each queue is empty
Disk
Server
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
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
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
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
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.
Optimistic replication
• Optimistic replication control protocols allow access in disconnected mode– Tolerate temporary inconsistencies– Promise to detect them later– Provide much higher data availability
Updated forFall 2012
Optimistic replication control putsdata availability above data consistency
Callbacks (I)
• 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
Updated forFall 2012
If machines could talk (I)
Client
I should contact the server each time I open
any file
Server
99% of these requests are useless!
If machines could talk (II)
Client
??
Server
You do not need to call me:I promise to call you back if anyone has modified the file
If machines could talk (III)
Client
What if I do not receive your
callback?
Server
Though luck!
Callbacks (II)
• Callbacks can be lost!
– Client will call the server every tauminutes 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
If machines could talk (IV)
Client
I will contact you from time to time to check
for lost callbacks
Server
Sure as long as you do not do it too frequently
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
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
Accessing large files
• When disk is powered down, Blue FS get first file blocks from remote server
Deciding which device to use
• If decisions are made for each individual access– Will never activate a disk that’s 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
Blue FS architecture (II)
Applications
BlueFS KernelModule
Wolverine
Linux Kernel
Linux File Cache
USBStick
CardFlash
Micro-drive
Local Disk
To BlueFS Server
VFS Operatio
ns
Up-call
Updated forFall 2012
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
Blue FS architecture (II)
Applications
BlueFS KernelModule
Wolverine
Linux Kernel
Linux File Cache
USBStick
CardFlash
Micro-drive
Local Disk
To BlueFS Server
VFS Operations
Up-call
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)
Interactive delay
Ten times faster than NFS, 16% faster than Coda WD
6000.0
Adding a 16MB flash drive
• Assumes that cache is fully loaded• 48% shorter interactive delay 48%, 25% less energy
0
20
40
60
80
100
120
140
160
180
200
0 ms delay 30 ms delay
Inte
ract
ive
Del
ay (
seco
nd
s)
Coda BlueFS BlueFS w/ Flash
0
100
200
300
400
500
600
700
800
0 ms delay 30 ms delayD
FS
En
erg
y (J
ou
les)
Energy efficiency
• Different benchmark run with half-full cache• 76% shorter interactive delay, 55% less energy than Coda
0
200
400
600
800
1000
1200
1400
1600
0 ms delay 30 ms delayD
FS
En
erg
y (J
ou
les)
Coda
BlueFS
0
100
200
300
400
500
600
700
800
0 ms delay 30 ms delay
Inte
rac
tiv
e D
ela
y (
se
co
nd
s)
Adding a 16MB flash drive
• Assumes that cache is fully loaded• 48% shorter interactive delay, 25% less energy
0
20
40
60
80
100
120
140
160
180
200
0 ms delay 30 ms delay
Inte
ract
ive
Del
ay (
seco
nd
s)
Coda BlueFS BlueFS w/ Flash
0
100
200
300
400
500
600
700
800
0 ms delay 30 ms delayD
FS
En
erg
y (J
ou
les)
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!
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