Image Size on Client Incorrect
-
@Developers This may need attention before 1.5.8 is released.
Mod note: Moving to bug reports
-
@Ben-Acheff Thanks for reporting this. I will try to replicate the issue and get back to you tomorrow.
-
@Ben-Acheff So far I wasn’t able to replicate the issue as described. Used resizable as well as non-resizable image type and did not see “image size on client” doubling when doing several captures in a row.
Not saying this is not happening to you or not a bug. Just I am not finding it yet. Can you describe with more detail? This is the same image (definition), right? Resizable or non-resizable or raw image type? Four captures means it shows ~80 GB in size, right?
-
I guess I’m a little confused as to the issue here.
Image Size on Client = the Hard drive size (roughly) after the image is shrunk in the case that it is shrunk.
So let’s say you captured an image that the original Hard Drive was 80GB at “full” capacity.
When you capture the image, let’s say it has 2 partitions for simplicity.
We’ll just presume Windows 7 for the partition structure again for simplicity.
Partition 1 = 100MB - This would be captured without resizing.Partition 2 = 79.9GB - This would be captured with resized.
As partition 2 is the shrinkable partition, and you sated you had windows installation of 30gb in size. So let’s just suggest the shrinking was able to leave 0 % free space so it shrinks the partition down to 30GB. (This doesn’t actually happen as we leave a 5% buffer to ensure the data has room to write to the drive but again for simplicity)
Well, at this point the minimal size of the disk to accept this particular image would have to be 30.1GB.
The math is pretty simple: take the blocks from partition 1 and partition 2, add them together and there you have the Image Size on Client.
So I guess what I’m trying to understand, as we don’t seem to have enough information to work from, is what the issue is and how we know it’s just “adding all prior image updates to the original cluster.”
So is what you’re saying is now you re-captured the same image so now it’s trying to say you have 60.2GB size on client?
Can you provide the image you’re seeing this issue with d1.minimum_partitions and d1.partitions files, as well the d1.fixed_size_partitions?
Maybe you’re capturing Multiple Disks? (Maybe the size you’re seeing as multiples of what is actually captured is due to multiple disks being picked up?)
-
@Sebastian-Roth The images are set reizeable, and yes, every time the image is updated, the file size is reported that it’s the sum of the old file size added to the new one.
We’ve verified that the image file is no where near as big as reported, but it’s strange that a file that takes up 8gb on our server is being reported as being over 50gb.
-
@Ben-Acheff Size on Client = original disk size, not the size of the file on the server. That’s what the Size on Server is for.
-
@Ben-Acheff Can you please post the contents of the text file
d1.minimum.partitionsthat you find in the image directory on the server? -
@Tom-Elliott No, I’m not capturing multiple partitions. The issue is, that for years the image size on client reflected a file size that would be normal for an image captured post-compression for storage, as in a 30gb Windows installation stored in an image file below 20gb. Each time that I’d update the image and re-upload it, the file size would stay approximately the same.
But in recent months, without warning, the image size on client in the web interface has been erroneously reporting that the image files were far larger than they actually were, essentially adding the old file size to the new one, resulting in a huge file report, despite not being that big.
-
@Ben-Acheff Can you post the contents of the d1.minimum.partitions file and a picture of what you’re describing?
For years,
Size on Server = Image File Size Post Compression.
Size on Client = (Roughly) Minimum required Hard Drive size.From what you’re describing, you’re mixing the two differences.
-
We have another report on this: https://forums.fogproject.org/topic/14249/image-size-of-the-client-in-fog-does-not-match-the-size-of-the-capture-in-hard-drive
@Ben-Acheff Still waiting for you to provide the contents of
d1.minimum.partitionsfrom your image. -
@Ben-Acheff Sorry, forgot to mention this is solved in
dev-branch(ref) and fix will be in the next release. -
I’ve seen the OP’s issue for several years on ~20 fog servers on various hardware platforms (virtual and bare metal), using both resized and non-resized images. I can confirm that this was still an issue on 1.5.8 but today I upgraded to 1.5.9 and it seems to be resolved. Old images still show the incorrect size, but recapturing them updates the image size on client to the correct value, which is approximately the minimum required hard drive capacity on the client when deploying the image.
