Paul Brook wrote: >>> What about another cache=... value instead of adding more options? I'm >>> quite sure you'll only ever need this with writeback caching. So we >>> could have cache=none|writethrough|writeback|wb-noflush or something >>> like that. >>> > > I agree. > > >> The cache option really isn't too useful. There's a matrix of 3x2 >> possible I/O modes for the posix backend, and right now we only expose >> two of them. I think we really should expose all of them, split into >> two options: >> >> caching >> >> | normal | O_DIRECT | >> >> --------+--------------------+--------------------+ >> none | - | - | >> integrity O_DSYNC | cache=writeback | - | >> fsync | cache=writethrough | cache=none | >> --------+--------------------+--------------------+ >> > > I think this table is misleading, and from a user perspective there are only > 4 > interesting combinations: > > cache=none: > No host caching. Reads and writes both go directly to underlying storage. > Useful to avoid double-caching. > > cache=writethrough > Reads are cached. Writes go directly to underlying storage. Useful for > broken guests that aren't aware of drive caches. > > cache=writeback > Reads and writes are cached. Guest flushes are honoured. Note that this may > include a guest visible knob that allows the write cache to be disabled. If > the guest requests the cache be disabled then this should act the same as > cache=writethrough. Closest to how real hardware works. > > cache=always (or a more scary name like cache=lie to defend against idiots) > Reads and writes are cached. Guest flushes are ignored. Useful for dumb > guests in non-critical environments. >
How about cache=insecure? But I agree. Having that as a cache= option seems to be the easiest way to expose it to a user. Alex
