OFS: An Overlay File System for Cloud-Assisted Mobile Applications - - PowerPoint PPT Presentation

ofs an overlay file system for cloud assisted mobile
SMART_READER_LITE
LIVE PREVIEW

OFS: An Overlay File System for Cloud-Assisted Mobile Applications - - PowerPoint PPT Presentation

OFS: An Overlay File System for Cloud-Assisted Mobile Applications Jianchen Shan, Nafize R. Paiker, Xiaoning Ding, Narain Gehani, Reza Curtmola, Cristian Borcea Mobile apps need cloud assistance Mobile devices have limited resources


slide-1
SLIDE 1

OFS: An Overlay File System for Cloud-Assisted Mobile Applications

Jianchen Shan, Nafize R. Paiker, Xiaoning Ding, Narain Gehani, Reza Curtmola, Cristian Borcea

slide-2
SLIDE 2

Mobile apps need cloud assistance

  • Mobile devices have limited resources
  • Systems designed to offload resource-

demanding tasks to cloud

  • Tasks offloaded in the forms of:

– Threads: CloneCloud [EuroSys ’11], COMET [OSDI ’12] – Procedures: MAUI [MobiSys ’10], ThinkAir [Infocom ’12] – Objects: Sapphire [OSDI ’14]

2

slide-3
SLIDE 3

Example of cloud-assisted mobile app

  • Enhanced camera app
  • 1. Take and store a photo

Cloud

  • 2. Offload image processing tasks
  • n the photo to the cloud

Mobile 3 Read the photo from mobile

  • 4. Do some processing on photo
  • 5. Update the photo
  • 6. Read the processed photo
  • 7. Display the processed photo
  • Characteristics of file I/O in cloud-assisted mobile apps:

– Read and write files on both mobile and cloud – May require strong consistency (always read latest copy) – Long I/O latency due to transferring the file over network

3

slide-4
SLIDE 4

Existing systems cannot handle file I/O in cloud-assisted mobile apps

  • Don’t support offloading tasks that perform file
  • perations

– COMET [OSDI ’12]

  • Don’t have mechanisms to support consistent

remote file access

– MAUI [MobiSys ’10], ThinkAir [Infocom ’12], CloneCloud [EuroSys ’11], Sapphire [OSDI ’14]

4

slide-5
SLIDE 5

Problems with using network and distributed file systems

  • Strong consistency cannot be achieved with low

latency and low network overhead

  • Opened files must be reopened after a task is
  • ffloaded in order to continue accessing the file

– Close → migrate → reopen

  • Root privilege needed to setup client software
  • User credentials need to be saved in the cloud to

access files

5

slide-6
SLIDE 6

File system requirements for cloud- assisted mobile apps

  • Location transparency

– Access remote files as though they were local – Maintain file sessions during task offloading

  • Consistency

– Ensure correct execution of tasks distributed across mobile and cloud

  • Performance

– Provide low latency with little network overhead to save energy and network bandwidth

  • Ease of deployment

– Require minimal privileges in addition to those needed to run tasks – No need to save to-be-accessed files before application runs

6

slide-7
SLIDE 7

Overlay file system (OFS)

  • Application-level FS for cloud assisted mobile apps

– Doesn’t need system-wide management – Can work with any native file system – Doesn’t incur costly context switches

  • Advantages:

– Strong consistency (delayed-update policy) – Location transparency (file session management) – Low overhead (low latency file access, low overhead consistency maintenance) – Ease of deployment (application level)

7

slide-8
SLIDE 8

Outline

  • Background
  • OFS

– Architecture and design – Consistency model

  • Evaluation
  • Conclusion and future work

8

slide-9
SLIDE 9

Local Offloading middleware Offloaded task Standard file I/O interface Offloading middleware Local O Mobile app Standard file I/O interface OFS Block buffer

Cloud Mobile device

OFS Block buffer

Consistency

Overall system architecture

  • OFS intercepts and monitors file access requests from

tasks in application

  • For remote file access, OFS maintains a block buffer to

cache blocks read from remote files through network

Block buffer Block buffer

9

slide-10
SLIDE 10

Buffer management Session management Local/remote access switch Standard file I/O interface to app To native file systems Block buffer Consistency management To other devices Interface to task

  • ffloading

middleware

OFS architecture

Upper layer: library linked with application Lower layer: app-level runtime service in middleware

10

slide-11
SLIDE 11

Buffer Session management Local/remote access switch Standard file I/O interface to app

  • other devices

Interface to task

  • ffloading

middleware Attached with application OFS middleware

  • Intercepts library calls
  • Decides whether a call should be handled by native

file system or OFS

  • Native file system: local files
  • OFS: remote files

OFS architecture

11

slide-12
SLIDE 12

Buffer management Session management Local/remote access switch Standard file I/O interface to app cy To other devices Interface to task

  • ffloading

middleware Attached with application OFS middleware

  • File session: set of file operations and states between file
  • pen and close
  • When a task is offloaded, the state required by the

unfinished file sessions will be correctly set up

OFS architecture

12

slide-13
SLIDE 13

management To native file systems Block buffer Consistency management To other devices task middleware

  • Utilizes the delay-update consistency model
  • Notified of all calls before it passes the calls to buffer

management

  • Confirms that writes will not cause inconsistency issues
  • Keeps access information for reads to detect access patterns

OFS architecture

13

slide-14
SLIDE 14

Buffer management Session management To native file systems Block buffer Consistency management To other devices Interface to task

  • ffloading

middleware OFS middleware

  • Caches only remote files
  • Data and metadata reside in virtual address space for fast access
  • Metadata maintains location and status of file blocks

OFS architecture

14

slide-15
SLIDE 15

Storage L h Session Manager Consistency Manager Buffer Manager OFS Middleware User App al/Remote Switch ession Manager Consistency Manager Buffer Manager OFS Middleware Cloud Storage

Mobile Cloud

OFS workflow: enhanced camera app

Take and store photo Is it remote? Store the photo locally no

Offload heavy workload thread from mobile to the cloud

15

slide-16
SLIDE 16

OFS Middleware OFS Middleware Local Storage Cloud Storage ssion Resume S p Update the photo Is it remote?yes Update file state Display the photo

Mobile Cloud Migrate the thread back to mobile from cloud

Load file blocks Maintain consistency between cloud and mobile If any of the file blocks in block buffer are invalid, fetch valid copies from cloud and return file blocks

OFS workflow: enhanced camera app

16

slide-17
SLIDE 17

User App Consistency Manager Buffer Manager OFS Middleware User App Local/Remote Switch Consistency Manager Buffer Manager OFS Middleware Cloud Storage

Mobile Cloud

Destroy Session Destroy Session Update file state

OFS workflow: enhanced camera app

17

Local Storage

slide-18
SLIDE 18

Outline

  • Background
  • OFS

– Architecture and design – Consistency model

  • Evaluation
  • Conclusion and future work

18

slide-19
SLIDE 19

T Cloud Mobile

Delayed-update algorithm

  • Monitor file access pattern to efficiently maintain

strong consistency

– Combination of write-invalidate and write-update

  • Invalidate duplicates
  • Update them when they are about to be read

w w w R

19

w

Invalidate

Update

w w w R w

Invalidate

… …

Update

slide-20
SLIDE 20

Outline

  • Background
  • OFS

– Architecture and design – Consistency model

  • Evaluation
  • Conclusion and future work

20

slide-21
SLIDE 21

Experiments

  • Goal: compare OFS against with write-invalidate,

write-update, and NFS

  • Traces: real-life mobile app file access traces

derived from U. of Buffalo’s PhoneLab testbed

– Thread offloading: offload complete threads – Procedure offloading: offload parts of threads

  • Metrics:

– Average read and write latency – Average I/O latency – Network overhead – Mobile device active time

21

slide-22
SLIDE 22

OFS incurs lowest I/O latency

Thread offloading Procedure offloading

  • 85%, 37%, and 33% lower latency than write-update, write-

invalidate, and NFS

  • Procedure offloading incurs 22% lower latency than

thread offloading

22

slide-23
SLIDE 23

OFS reduces read latency at the cost

  • f write latency
  • Read latency is 14x lower, and write latency is 2-3x higher than write

invalidate and NFS

  • Read-intensive workloads benefit more from OFS than write-intensive

workloads

Thread offloading Procedure offloading 23

slide-24
SLIDE 24

OFS achieves lower I/O latency with slightly higher network overhead

  • 6% higher network overhead than write-invalidate and NFS
  • Procedure offloading leads to lower network overhead than thread
  • ffloading

24

slide-25
SLIDE 25

OFS reduces mobile device active time more effectively than other policies

Procedure offloading

  • I/O overhead must be effectively reduced to really benefit from

task-offloading to the cloud

  • Speedup application and save battery power

25

slide-26
SLIDE 26

Conclusion and future work

  • OFS provides efficiency, consistency, and location

transparency

  • OFS lowers substantially file access latency at the cost of

small network overhead

  • OFS reduces the active time of mobile devices when

running cloud-assisted apps

  • OFS is more effective with read-intensive workloads and

procedure offloading

  • Future work: integrating OFS in our Moitree middleware

26

slide-27
SLIDE 27

Thanks!

http://cs.njit.edu/~borcea/avatar

Acknowledgment: NSF Grants CNS 1409523, CNS 1054754, DGE 1565478, and DUE 1241976. NSA Grant H98230-15-1-0274, DARPA/AFRL Contract: A8650-15-C-7521.

27

slide-28
SLIDE 28

Backup slides

28

slide-29
SLIDE 29

Consistency management in OFS

  • Objectives:

– Strong consistency

  • No stale data => application correct execution, simple

application development

– Low access latency and network overhead

  • Write-invalidate and write-update

– Relaxed consistency

  • Health monitoring app

29

slide-30
SLIDE 30

Delayed-update algorithm

  • Monitor file access pattern to determine

when to update duplicates

– Combination of write-invalidate and write-update – Invalidate duplicates and then update them when they are about be to read

T Cloud Mobile w w w w w w w w w w w w w w w Overwritten counter = Overwritten threshold = 1 2 3 R R R R R R R

Invalidate Invalidate update Invalidate update Invalidate miss hit hit miss hit miss hit

3 2 1 2 1

update update Invalidate

2 1 2 1 3 2 1 1 1

Invalidate

30

slide-31
SLIDE 31

Delayed-update algorithm

  • Monitor file access pattern to efficiently maintain

strong consistency

– Combination of write-invalidate and write-update – Invalidate duplicates; update them when they are about be to read

T Cloud Mobile w w w w w w w w w w w w w w w R R R R R R R

Invalidate Miss Hit Hit Miss Hit Miss Hit Invalidate Update Invalidate Update Invalidate Update Invalidate Update Invalidate

31

slide-32
SLIDE 32

Number of overwrites per transfer

Thread offloading Procedure offloading

  • OFS transfer data more frequently than write-invalidate and NFS
  • Cannot accurately predict and may update data too soon
  • Explain why OFS incurs slightly higher write latency and network overhead
  • OFS transfer data less frequently for procedure offloading
  • Explain why procedure offloading perform better than thread offloading in terms of

write latency and network overhead

32

slide-33
SLIDE 33

Block buffer hit ratio

Thread offloading Procedure offloading

  • OFS has higher hit ratio than write-invalidate and NFS (99% Avg)
  • Indicates that the delayed-update algorithm in OFS can effectively adjust

the overwrite threshold and update duplicates to minimize buffer misses

  • Explains why OFS has lower read latency
  • Procedure offloading has higher hit ratio than thread offloading
  • Explains why the read latency is lower for procedure offloading than for thread
  • ffloading

33