Am 14.08.2018 um 13:34 hat Leonid Bloch geschrieben: > On 8/14/18 11:18 AM, Kevin Wolf wrote: > > Am 13.08.2018 um 18:42 hat Leonid Bloch geschrieben: > > > > I don't actually think it's so bad to keep the cache permanently > > > > allocated, but I wouldn't object to a lower default for non-Linux hosts > > > > either. 1 MB may still be a little too low, 4 MB (covers up to 32 GB) > > > > might be more adequate. My typical desktop VMs are larger than 8 GB, but > > > > smaller than 32 GB. > > > > > > And for a Windows VM just the OS installation takes above 40 GB. While we > > > probably are not running Windows VMs for our own needs, it is very common > > > that a customer of, for example, some cloud service uses QEMU > > > (unknowingly) > > > for a full-blown Windows. So 100 GB+ images which are quite heavily used > > > is > > > not a rare scenario. 256 GB - yeah, that would be on the higher end. > > > > The OS installation is mostly sequential access, though. You only need > > that much cache when you have completely random I/O across the whole > > image. Otherwise the LRU based approach of the cache is good enough to > > keep those tables cached that are actually in use. > > Sorry, by "OS installation" I meant the installed size of the OS, which > should be available for fast and frequent access, not the installation > process itself. Obviously for one-time tasks like the installation process > it's not worth it, unless one installs all the time, instead of using ready > images, for some reason. :)
But you never use everything that is present in an OS installation of 40 GB (is it really _that_ huge these days?), and you don't read OS files non-stop. The most frequently used parts of the OS are actually in the guest RAM. I don't think you'll really notice the difference in qcow2 unless you have a really I/O intensive workload - and that is not usually for OS files, but for user data. For only occasional accesses, the additional 64k for the metadata table wouldn't play a big role. Kevin
