Does exporting Linked Clones flatten them? Do linked clones add wear and tear to SSDs?

[wat]

I was wondering if I could turn a linked clone back into a full clone with the export feature, otherwise backup would be more complicated.

Also wondering if linked clones do more writes to the harddrive, saving state of a linked clone seems to take much longer, writes matter for ssd's.

Also can the linked clone vdi files be compacted using clonevdi once they suffer bloat? I originally chose linked clones to save space, but if they cannot be compacted in the future to remove slack space that effort would be defeated.

[mpack]

Why would you need to use the export feature? If all you want to do is created a flattened clone then use the VM clone function, tell it to clone the current state only.

No, saving the state of a linked clone should not take appreciably longer than any other VM. That said, if the VM is already on an SSD then I wonder what saving state buys you. Why not fully shut down the VM? That way saving state will take 0 seconds.

[wat]

Ah ok I guess that worked, the Ubuntu 18.04 linked guest is 1.93GB, the full clone of the linked guest is 6.11GB

The exported appliance is 1.9GB~ meaning its not flattened and useless, I wonder why they did that.

After looking into it, the save time seems to be affected by the amount of ram allocated to the guest, even with an ssd, it was taking 30 seconds to save the state with 2GB of ram, dropping it to 1, then 512MB cut the time significantly, though its not a solution and I guess its just better to shut down instead, except that the rewriting of the linked snapshot takes even longer if just for the first time abandoning saved states, I guess it was rewriting the snapshot down to 1.08GB. Subsequent shutdowns were within 3 seconds.

I guess the lesson is not to use saved states.

[mpack]

Saving state doesn't involve any writes to a snapshot VDI (other than a normal buffer flush), so you should perhaps re-evaluate what you're seeing there.

Yes, saving state basically means saving the contents of RAM, plus the register contents of simulated hardware (but the latter is negligable - we can ignore). Hence it will be dominated by the amount of RAM allocated to the VM and the speed of the hdd.

If you have an SSD then loading and initializing a VM from scratch should take hardly any longer than a load from a hibernation file followed by sanity checks. IMHO it makes little sense to use saved states on an SSD, and no more sense to cripple the VM in order to make a task that occupies 0.1% of session time run a little faster.

[wat]

It may have been ubuntu installing a patch altering the size, I'm not sure.

[mpack]

even with an ssd, it was taking 30 seconds to save the state with 2GB of ram

I've been thinking about this comment, and there must be something else going on here.

2GB (2048MB) written in 30 seconds equates to ~68MB/second. Decent SSDs ought to have write speeds around 500MB/s, so I suspect that your host is misconfigured somehow.

Are you sure the drive is really an SSD and not a USB3 flash drive? 68MB/s would be semi decent for the latter. Likewise 68 mb/s would be quite decent for a mechanical drive.

[wat]

It was a bit odd.
http://ssd.userbenchmark.com/Compare/Sa ... 2548vs2977
Its an old sandisk ultra II 240GB(60% empty), which is a dumping ground for things like this. I do have ntfs file compression on, not that it should make that much of a difference, its an i7 with 32GB of ram.

[mpack]

I would turn NTFS compression off. It's a complete waste of time (literally), unless your data mainly consists of huge text files. It will cripple an SSD. It will be a killer for VM work on any drive type.

If you have individual files that would benefit from compression then considering storing them in compressed folders.

[wat]

ntfs compression did almost halve the disk usage, but I guess the cost in performance is too high in this case, save state after decompressed was much faster. I guess mixed io is much worse than with games where the compression doesn't hurt at all now.

[mpack]

Yes, compression may give you more disk space, at a significant cost in performance, but only if the data happens to be highly compressible (i.e. not binaries or things like jpegs that have already been compressed): though it's usually more sensible to use a larger disk drive. And the data also has to be essentially static and streamed: seek can't work efficiently if the record is at a unknown and variable offset from the origin. And if you have to write into the middle of a large file, thus changing the compressibility of just that section... heaven forbid. The only solutions I can think of have horrific penalties involved.

The only argument I ever heard in favor of drive compression went something like: yes, executing the compression algorithms takes a lot of CPU time, but you get it back in I/O time because you have less real I/O to do. But that argument no longer makes sense on SSDs (where I/O costs are much lower) and most modern I/O is done using background DMA anyway, so the CPU should never actually be waiting.

Frankly, until this conversation I had thought that drive compression was a gimmick whose time never quite came and then quickly went again sometime in the '90s or '00s. The idea never stood up to even a moment of scrutiny.