Am 22.02.2011 09:37, schrieb Markus Armbruster: > Anthony Liguori <anth...@codemonkey.ws> writes: > >> On 02/18/2011 03:57 AM, Kevin Wolf wrote: >>> Am 18.02.2011 10:12, schrieb Markus Armbruster: >>> >>>> Kevin Wolf<kw...@redhat.com> writes: >>>> >>>> >>>>> Am 15.02.2011 20:45, schrieb Chunqiang Tang: >>>>> >>>>>>> Chunqiang Tang/Watson/IBM wrote on 01/28/2011 05:13:27 PM: >>>>>>> As you requested, I set up a wiki page for FVD at >>>>>>> >>>>>> http://wiki.qemu.org/Features/FVD >>>>>> >>>>>>> . It includes a summary of FVD, a detailed specification of FVD, and a >>>>>>> comparison of the design and performance of FVD and QED. >>>>>>> >>>>>> >>>>>>> See the figure at http://wiki.qemu.org/Features/FVD/Compare . This >>>>>>> >>>>>> figure >>>>>> >>>>>>> shows that the file creation throughput of NetApp's PostMark benchmark >>>>>>> >>>>>> under >>>>>> >>>>>>> FVD is 74.9% to 215% higher than that under QED. >>>>>>> >>>>>> Hi Anthony, >>>>>> >>>>>> Please let me know if more information is needed. I would appreciate your >>>>>> feedback and advice on the best way to proceed with FVD. >>>>>> >>>>> Yet another file format with yet another implementation is definitely >>>>> not what we need. We should probably take some of the ideas in FVD and >>>>> consider them for qcow3. >>>>> >>>> Got an assumption there: that the one COW format we need must be qcow3, >>>> i.e. an evolution of qcow2. Needs to be justified. If that discussion >>>> has happened on the list already, I missed it. If not, it's overdue, >>>> and then we better start it right away. >>>> >>> Right. I probably wasn't very clear about what I mean with qcow3 either, >>> so let me try to summarize my reasoning. >>> >>> >>> The first point is an assumption that you made, too: That we want to >>> have only one format. I hope it's easy to agree on this, duplication is >>> bad and every additional format creates new maintenance burden, >>> especially if we're taking it serious. Until now, there were exactly two >>> formats for which we managed to do this, raw and qcow2. raw is more or >>> less for free, so with the introduction of another format, we basically >>> double the supported block driver code overnight (while not doubling the >>> number of developers). >>> >> >> Not sure what project you're following, but we've had an awful lot of >> formats before qcow2 :-) >> >> And qcow2 was never all that special, it just was dropped in the code >> base one day. You've put a lot of work into qcow2, but there are >> other folks that are contributing additional formats and that means >> more developers. >> >>> The consequence of having only one file format is that it must be able >>> to obsolete the existing ones, most notably qcow2. We can only neglect >>> qcow1 today because we can tell users to use qcow2. It supports >>> everything that qcow1 supports and more. We couldn't have done this if >>> qcow2 lacked features compared to qcow1. >>> >>> So the one really essential requirement that I see is that we provide a >>> way forward for _all_ users by maintaining all of qcow2's features. This >>> is the only way of getting people to not stay with qcow2. >>> >>> >>> Of course, you could invent another format that implements the same >>> features, but I think just carefully extending qcow2 has some real >>> advantages. >>> >>> The first is that conversion of existing images would be really easy. >>> Basically increment the version number in the header file and you're >>> done. Structures would be compatible. >> >> qemu-img convert is a reasonable path for conversion. >> >>> If you compare it to file systems, >>> I rarely ever change the file system on a non-empty partition. Even if I >>> wanted, it's usually just too painful. Except when I was able to use >>> "tune2fs -j" to make ext3 out of ext2, that was really easy. We can >>> provide the same for qcow2 to qcow3 conversion, but not with a >>> completely new format. >>> >>> Also, while obsoleting a file format means that we need not put much >>> effort in its maintenance, we still need to keep the code around for >>> reading old images. With an extension of qcow2, it would be the same >>> code that is used for both versions. >>> >>> Third, qcow2 already exists, is used in practice and we have put quite >>> some effort into QA. At least initially confidence would be higher than >>> in a completely new, yet untested format. Remember that with qcow3 I'm >>> not talking about rewriting everything, it's a careful evolution, mostly >>> with optional additions here and there. >>> >> >> My requirements for a new format are as followed: >> >> 1) documented, thought-out specification that is covered under and >> open license with a clear process for extension. >> >> 2) ability to add both compatible and incompatible features in a >> graceful way >> >> 3) ability to achieve performance that's close to raw. I want our new >> format to be able to be used universally both for servers and >> desktops. > > I'd like to add > > 4) minimize complexity and maximize maintainability of the code. I'd > gladly sacrifice nice-to-have features for that.
Especially if they are features that only other users use, right? What's the "Sankt-Florians-Prinzip" called in English? >> I think qcow2 has some misfeatures like compression and internal >> snapshots. I think preserving those misfeatures is a mistake because >> I don't think we can satisfy the above while trying to preserve those >> features. If the image format degrades when those features are >> enabled, then it decreases confidence in the format. > > I'm inclined to agree. There's one way to prove us wrong: implement the > misfeatures without compromising the requirements. *sigh* It starts to get annoying, but if you really insist, I can repeat it once more: These features that you don't need (this is the correct description for what you call "misfeatures") _are_ implemented in a way that they don't impact the "normal" case. And they are it today. Kevin
