Michelle L. Mazurek, Carnegie Mellon University; Eno Thereska, Dinan Gunawardena, Richard Harper, and James Scott, Microsoft Research, Cambridge, UK
My takeaway: interesting framework....
This is mainly a mircosoft study (comes from an internship)
Personal data requires collaboration, and coordinating device,
Key problem: unavailable devices (offline laptop?)
Eventual consistency (like Coda) is now data now. Public cloud not that trust worthy.
ZZFS key idea: turn on devices that are off!
Human factor important!
Hardware: NIC always on transparent to applications
System design:
meta-deta service: flat, device transparent namespace. Single instance, cached on all device
I/O director: where to read/write data (different polcy can apply)
write through to all copies. If device nto available, may write to a log.
Evaluation: read latency to retrive a song when device is shutting down: 23s
write latency when device not availabe and offload (0.2-1s latency)
Q&A:
Q: Some noise in measurments
A: Comes from a bad wireless router maybe?
Q: public cloud really not trust worthy?
A: We are just offering alternatives
Q: more details in cache?
A: Sychrounously and searized writes. And we build upon sth. which has strong consistency.
Revisiting Storage for Smartphones
Hyojun Kim, Nitin Agrawal, and Cristian Ungureanu, NEC Laboratories America
This is mainly a mircosoft study (comes from an internship)
Personal data requires collaboration, and coordinating device,
Key problem: unavailable devices (offline laptop?)
Eventual consistency (like Coda) is now data now. Public cloud not that trust worthy.
ZZFS key idea: turn on devices that are off!
Human factor important!
Hardware: NIC always on transparent to applications
System design:
meta-deta service: flat, device transparent namespace. Single instance, cached on all device
I/O director: where to read/write data (different polcy can apply)
write through to all copies. If device nto available, may write to a log.
Evaluation: read latency to retrive a song when device is shutting down: 23s
write latency when device not availabe and offload (0.2-1s latency)
Q&A:
Q: Some noise in measurments
A: Comes from a bad wireless router maybe?
Q: public cloud really not trust worthy?
A: We are just offering alternatives
Q: more details in cache?
A: Sychrounously and searized writes. And we build upon sth. which has strong consistency.
Revisiting Storage for Smartphones
Hyojun Kim, Nitin Agrawal, and Cristian Ungureanu, NEC Laboratories America
My takeaway: for mobile app, I/O (esp. random I/O) matters! Not just network you should worry about. And don't buy kingston SD card :p
Best paper!
Loading time bad for mobile users! But aren’t netowrk and CPU real problem?
Background: network considers improtant, CPU/graphics also consider improtant, but storage performance impact not well understood.
Why storage is a problem?
1. random I/O worse than seq with flash storage (even worth than wireless. But flash classified based on sequential throughput
2. app use random I//O
Measurements:
1. storage affects performance!
2. SD speed class not really indicative
Experimental Results:
Performance varies for different SD cards! (Kinston 200x slower!) Even faster wifi, not faster app runtime.
2x sequential writes than randome wrties, but 4-1000x random/sequential performance difference on SD card, so random access bottleneck
Why so muich random I/O: some data in FS (cached), and some data written to SQLite in sync
Thus placing DB will improve performance, or just disable SD sych mode...
Solutions:
RAID-0 over sd?
Log structured file system?
App specific selective sync?
Q&A：
Q: reminds me of Wisconsin paper. Are we now dealing with stupid applications?!!!
A: app written in modular way, and become performance oblivious. There are tradeoffs, and we need to be a bit more flexible.
Q; does performance matter? Maybe UI more important for end-to-end experience.
A: We actually wait for app to load data.
Serving Large-scale Batch Computed Data with Project Voldemort
Roshan Sumbaly, Jay Kreps, Lei Gao, Alex Feinberg, Chinmay Soman, and Sam Shah, LinkedIn Corp
My takeaway: didn't quite understand this one...seems like storage tailered for distributed key-value store?
Loading time bad for mobile users! But aren’t netowrk and CPU real problem?
Background: network considers improtant, CPU/graphics also consider improtant, but storage performance impact not well understood.
Why storage is a problem?
1. random I/O worse than seq with flash storage (even worth than wireless. But flash classified based on sequential throughput
2. app use random I//O
Measurements:
1. storage affects performance!
2. SD speed class not really indicative
Experimental Results:
Performance varies for different SD cards! (Kinston 200x slower!) Even faster wifi, not faster app runtime.
2x sequential writes than randome wrties, but 4-1000x random/sequential performance difference on SD card, so random access bottleneck
Why so muich random I/O: some data in FS (cached), and some data written to SQLite in sync
Thus placing DB will improve performance, or just disable SD sych mode...
Solutions:
RAID-0 over sd?
Log structured file system?
App specific selective sync?
Q&A：
Q: reminds me of Wisconsin paper. Are we now dealing with stupid applications?!!!
A: app written in modular way, and become performance oblivious. There are tradeoffs, and we need to be a bit more flexible.
Q; does performance matter? Maybe UI more important for end-to-end experience.
A: We actually wait for app to load data.
Serving Large-scale Batch Computed Data with Project Voldemort
Roshan Sumbaly, Jay Kreps, Lei Gao, Alex Feinberg, Chinmay Soman, and Sam Shah, LinkedIn Corp
My takeaway: didn't quite understand this one...seems like storage tailered for distributed key-value store?
batch computed algorithm, map-reduce (hadoop)
Full refresh output instad of incremental
Voldemort: distributed key-value system. Baically Dynamo’s clone
Custom Voldemort Storage Enginee
ransform hadoop output to construct store.
a folder for every store, inside store, keeps multple verisons of data
Full refresh output instad of incremental
Voldemort: distributed key-value system. Baically Dynamo’s clone
Custom Voldemort Storage Enginee
ransform hadoop output to construct store.
a folder for every store, inside store, keeps multple verisons of data
没有评论:
发表评论