Features/QED/OutstandingWork

From QEMU
Revision as of 19:52, 12 January 2011 by Stefanha (talk | contribs) (Created page with 'Thanks to Kevin Wolf for collecting these points: * Relying on file size - have we really considered all cases with respect to data integrity? * Code review has brought up some…')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Thanks to Kevin Wolf for collecting these points:

  • Relying on file size - have we really considered all cases with respect to data integrity?
  • Code review has brought up some corruption issues that are fixed by now, but have we covered everything?
    • First dirty flag had to be added
    • Then a bdrv_flush after COW
    • What's next?
  • Planned incompatible changes must be done as soon as possible. Checked this with Stefan, it's only zero cluster support.
  • After a host crash an fsck is needed. Did anyone measure the time to start up when multiple guests on multiple hosts are recovering from a system failure? File system guys consider this a severe problem. [Update: Stefan has tested fsck time, but only with one image]
  • Migration currently doesn't work with QED, likely breaks images
  • QED doesn't work on block devices (required for some users)
  • No support for encryption, compression, internal snapshots
  • Non-technical issues:
    • Burden of maintaining an additional image format (basically doubles image format related work; both development and QA) [Update: Sharing code might reduce the burden, though I guess for QA purposes it would stay two independent formats.]
    • There are concerns that starting with a simple image format core and then adding one new thing after another on top is going to make code complexity grow very fast.
    • Conversion of existing images is needed to take advantage of QED.