On Tue, May 25, 2010 at 07:59:18PM +0200, Alexander Graf wrote: > 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. > > So what exactly is the conclusion here? I really want to see this > getting merged >
I really think this patch can be useful, in my own case when testing debian-installer (I already cache=writeback). In short all that is about developing and testing, as opposed to run a VM in production, can benefit about that. This was one of the original use case of QEMU before KVM arrived. Unless someone can convince me not to do it, I seriously considering applying this patch. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
