Am 26.05.2010 16:08, schrieb Anthony Liguori: > On 05/26/2010 09:03 AM, Kevin Wolf wrote: >> Am 26.05.2010 15:42, schrieb Anthony Liguori: >> >>> On 05/26/2010 03:43 AM, Kevin Wolf wrote: >>> >>>> Am 26.05.2010 03:31, schrieb Anthony Liguori: >>>> >>>> >>>>> On 05/25/2010 04:01 PM, Aurelien Jarno wrote: >>>>> >>>>> >>>>>> 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. >>>>>> >>>>>> >>>>>> >>>>> There really needs to be an indication in the --help output of what the >>>>> ramifications of this option are, in the very least. It should also be >>>>> removable via a ./configure option because no sane distribution should >>>>> enable this for end users. >>>>> >>>>> >>>> We know better what you stupid user want? >>>> >>> What percentage of qemu users do you think have actually read qemu-doc.texi? >>> >> As I said, put the warning in the option name like cache=unsafe or >> something even more scary and I'm all for it. >> >> >>> It's not a stretch for someone to have heard that cache options can >>> improve performance, and then see cache=volatile in the help output, try >>> it, and then start using it because they observe a performance improvement. >>> >>> That's not being stupid. I think it's a reasonable expectation for a >>> user to have that their data is safe. >>> >> You seem to think that the user is too stupid to allow him to use this >> option even if he's perfectly aware what it's doing. It's a useful >> option if it's used right. >> > > No, that's not what I said. I'm saying we need to try hard to make a > user aware of what they're doing. > > If it spit out a warning on stdio, I wouldn't think a compile option is > needed. Even with help output text, I'm concerned that someone is going > to find a bad example on the internet. > > cache=unsafe addresses the problem although I think it's a bit hokey.
Then let's do it this way. I'm not opposed to a stdio message either, even though I don't think it's really necessary with a name like cache=unsafe. I just say that disabling the option is not a solution because it prevents valid use. >> We need to make clear that it's dangerous when it's used in the wrong >> cases (for example by naming), but just disabling is not a solution for >> that. You don't suggest that "no sane distribution" should ship rm, >> because it's dangerous if you use it wrong, do you? >> > > You realize that quite a lot of distributions carry a patch to rm that > prevents a user from doing rm -rf /? Most rm invocations that I regretted later were not rm -rf /. Actually, I think rm -rf / is not among them at all. ;-) And I seem to remember that even these rm patches still allow the protection to be overridden by some force flag. But I've never tried it out. Kevin
