today:
big box storage dominates, but the selling point is just the software
so go from software/hardware to software/vmm/hardware
problem:
1. reliability
when errors are propagated, where in the system are the errors handled? -- file system just lost errors during propagation! (like 1/10)
error handling is fundamentaly hard (not because linux is written in C, or because it is open sourced thus poorly programmed)
how to reasonable about system error profile?
2. isolation
storage isolated from VM to VM
question: how does fs react to block failures? (type aware fault injection) -- Remzi somehow linked this work to fault isolation =,= ----- get a result matrix on how file system react to different types of faults -- write errors are largely ingnored by ext3 or other file systems, sometimes they panic too (for reitherfs)
so if one vm does something funny, it might cause the underly storage system to panic -- thus need to isolate faults systematically.
3. performance
how does performance change when you stack storage systems (say file systems) together, and how to systematically reason about it
4. application
how applications use storage (something along the line of Tyler's file is not a file paper)
beyond virtualization:
composition of storage!
Questions:
1. have you seen correctness guarantees been breaken?
Of course! Disk lie. Apple just change the semantics of fsync
2. how about error propagation in a layered storage?
we are doing that work. but we have shown that error propagation in a single layer is hard, could imagine it even worse for multiple virtualized storage layers
3. your vision of software defined storage is quite different with sdn? how do you relate your work to sdn, and maybe some analogy of sdn on how to manage storage?
we are starting small, and on problems we have already seen.
(i personally think remzi doesn't have a good answer on sdn-flavor like sds, in terms of storage control plane , yet...)
没有评论:
发表评论