Why does creating a fixed size VDI take so long?

[adrianh]

What exactly is it doing to take so long? Zeroing all the bytes or what? Or is this something that for safety to ensure the drive is not faulty?


A

[Perryg]

Yes and it is not necessary to use fixed and even can cause you issues later.

[adrianh]

Can you be more specific than 'yes'? I gave a couple of options.

I'm creating a fixed for a specific reason. So that the drive that I use doesn't overcommit. This is important.

Are there structures inside that of a fixed .vdi? Are they located at the begining or scattered throughout the drive?

[Perryg]

it zeros out the entire virtual drive.

[adrianh]

it zeros out the entire virtual drive.

So there are no structures in it? Then I can just create a large file and say that it is a vdi like a raw disk in file format?

[adrianh]

Yes and it is not necessary to use fixed and even can cause you issues later.

BTW, what issues were you referring to?

[Perryg]

You will not be able to expand the drive.

[mpack]

You will not be able to expand the drive.

And, because it's fixed size people tend to make them small, so they get congestion and crap performance.

Personally, I don't see a problem with overcomitting.

[adrianh]

As a backup server's backup drive, it isn't a problem. And it may increase throughput since it is not managing file sizes and cluster allocation.

[adrianh]

it zeros out the entire virtual drive.

So there are no structures in it? Then I can just create a large file and say that it is a vdi like a raw disk in file format?

BTW, am I correct in that there are no structures in it? Can I just create a massive file and be done with it?

[Perryg]

You can do what ever you want. As a suggestion though I would use the dynamic drive and set the max to be what ever you want (it will not get any bigger). There is talk that the fixed size is faster but that is just talk IMHO. To me there is simply no reason to fill a space with air. If you fill either one up you will have issues anyway. You should be aware of the drive capacity anyway and not run into a full disk.

[adrianh]

This is for a backup system that is not under my control, so I don't want a user to mess things up without realising it by writing to the physical disk.

BTW, nobody has explicitly said either way if a fixed VDI actually has any structures or not.

[mpack]

Yes, a fixed VDI has structure, in fact it has the exact same internal structure as a dynamic VDI (which is part of the reason why grand claims about performance are nonsense). The only difference is that, in the fixed sized variant, all blocks are preallocated at create time, instead of being allocated on demand.

[michaln]

Yes, a fixed VDI has structure, in fact it has the exact same internal structure as a dynamic VDI (which is part of the reason why grand claims about performance are nonsense). The only difference is that, in the fixed sized variant, all blocks are preallocated at create time, instead of being allocated on demand.

The consequence of preallocation is that fragmentation is minimized (ideally none whatsoever), and that can only improve performance. So yes, the internal structure is the same, but that doesn't mean the behavior is identical.

That said, for most uses there's no point in using fixed VDIs. Dynamically allocated images perform quite well, and I'm not aware of a case where the dynamic allocation would result in a performance bottleneck.

[mpack]

The consequence of preallocation is that fragmentation is minimized (ideally none whatsoever), and that can only improve performance. So yes, the internal structure is the same, but that doesn't mean the behavior is identical.

The marginal difference caused by internal block order fragmentation can be eliminated at any time by cloning the drive, especially convenient if done using CloneVDI with the "keep UUID" option set.

Of course a humungous fixed size drive image is more likely to be fragmented as a file on the host drive, so IMHO most users will see no difference in net effect. In fact it would pay to defragment the VDI, then defragment the host using a different tool - after the file size has stablilized of course. That should achieve the perfect ideal of compactness and performance.