Am 17.05.2010 22:07, schrieb Jamie Lokier: > Alexander Graf wrote: >> >> On 17.05.2010, at 18:26, Anthony Liguori wrote: >> >>> On 05/17/2010 11:23 AM, Paul Brook wrote: >>>>>> I don't see a difference between the results. Apparently the barrier >>>>>> option doesn't change a thing. >>>>>> >>>>> Ok. I don't like it, but I can see how it's compelling. I'd like to >>>>> see the documentation improved though. I also think a warning printed >>>>> on stdio about the safety of the option would be appropriate. >>>>> >>>> I disagree with this last bit. >>>> >>>> Errors should be issued if the user did something wrong. >>>> Warnings should be issued if qemu did (or will soon do) something other >>>> than >>>> what the user requested, or otherwise made questionable decisions on the >>>> user's behalf. >>>> >>>> In this case we're doing exactly what the user requested. The only >>>> plausible >>>> failure case is where a user is blindly trying options that they clearly >>>> don't >>>> understand or read the documentation for. I have zero sympathy for >>>> complaints >>>> like "Someone on the Internet told me to use --breakme, and broke thinks". >>>> >>> >>> I see it as the equivalent to the Taint bit in Linux. I want to make it >>> clear to users up front that if you use this option, and you have data loss >>> issues, don't complain. >>> >>> Just putting something in qemu-doc.texi is not enough IMHO. Few people >>> actually read it. >> >> But that's why it's no default and also called "volatile". If you prefer, we >> can call it cache=destroys_your_image. > > With that semantic, a future iteration of cache=volatile could even > avoid writing to the backing file at all, if that's yet faster. I > wonder if that would be faster. Anyone fancy doing a hack with the > whole guest image as a big malloc inside qemu? I don't have enough RAM :-)
But then you'd probably want a separate RAM block driver instead of messing with cache options. Kevin
