Features/QED/OutstandingWork: Difference between revisions

Revision as of 11:07, 1 February 2011

Outstanding features

Zero clusters
- Patch on mailing list, awaiting review and merge.

Reducing time window during which dirty flag is set
- Images with backing file don't need to set dirty bit during allocating write [merged].
- Piggyback clearing dirty bit on guest flush operation.
- Periodic flush in order to clear dirty bit.

Block device support (i.e. QED on LVM volumes)
- Solution: Keep a physical file size field in the QED header, update lazily using dirty bit logic

Live migration on shared storage
- Reopen file (open read-only first to prevent consistency check).

Encryption

Possible future work

Discard support
- Solution: Add a freelist to the image format
- Solution: Pass discard to underlying file. Loses compact image characteristic.

Internal snapshots
- Probably not worth adding since external snapshotting is being implemented

Compression
- No strong use case for this feature

Non-technical issues

Thanks to Kevin Wolf for contributing these points:

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.
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?

@@ Line 1: / Line 1: @@
-Thanks to Kevin Wolf for collecting these points:
+==Outstanding features==
-* Relying on file size - have we really considered all cases with respect to data integrity?
+* Zero clusters
+** Patch on mailing list, awaiting review and merge.
+* Reducing time window during which dirty flag is set
+** Images with backing file don't need to set dirty bit during allocating write '''[merged]'''.
+** Piggyback clearing dirty bit on guest flush operation.
+** Periodic flush in order to clear dirty bit.
+* Block device support (i.e. QED on LVM volumes)
+** Solution: Keep a physical file size field in the QED header, update lazily using dirty bit logic
+* Live migration on shared storage
+** Reopen file (open read-only first to prevent consistency check).
+* Encryption
+==Possible future work==
+* Discard support
+** Solution: Add a freelist to the image format
+** Solution: Pass discard to underlying file.  Loses compact image characteristic.
+* Internal snapshots
+** Probably not worth adding since external snapshotting is being implemented
+* Compression
+** No strong use case for this feature
+==Non-technical issues==
+Thanks to Kevin Wolf for contributing these points:
+* 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.
 * 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
-* Discard support not trivial, requires addition of some data structures to the format
-* 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.