> > 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. IMO the other boxes in your table (disable cache but require guest flushes) don't make any sense. Paul
