Comment 16 for bug 1974100

Hi Brent,

> can you run qemu from the command line on a bare metal system? If so, I thought my May 20 procedure was pretty simple.

Oh yes you can run it from cli on bare metal - and your procedure was indeed simple and very useful. I was not trying to challenge any of that - sorry if that was misleading.

Trying again :-): Qemu is like a swiss army knife, doing plenty of things and learning new twists every now and then. The command line can do all of it and due to that it might be that you find plenty of howtos (or just people trying options) that - to stay in the swiss army knife metaphor - still use the blade to cut down a tree. It does work, but in the meantime a saw was added which is much better for the task. That is what here virtio is to ide/sata.
It is in no way "invalidating" that there seems to be an issue with what ide/sata announces and how it then works - but it lowers the severity of this case a lot.

> I haven't tried all of your combinations ...

Thanks for trying the most important ones - that was enough IMHO.

I think with the info so far, by now we might have to split this discussion into two - almost separate - cases:

a) what/why is going on with discard on ide/sata attachments, confirmed but prio rather low (as outlined above)

b) Why are the unused non-zero blocks on a extended cloud-image used as root grow

We might later need to split out an extra bug for (b), but for now I've added a bug task here (they might know more, maybe have already seen or discussed it before)

I think by now for (b) we confirmed:
1. A new fs on those disks has no lost blocks
2. The cloudimage extended has a few lost blocks (12KB - neglegible)
3. The cloudimage extended and used as root grows more lost blocks (seems like 5 MB above)

I could try explain the few lost ones in #2 by padding when creating the image.
But why are they increasing more when used as root device - that I can't explain yet.

@CPC team - do you happen to know more about this already?