Sparsedisk Image Size comparasin anomoly

jwink3101jwink3101
Posted:
in macOS edited January 2014
I know that creating a Sparsedism image will still take some room when empty. Well, i decided to try and figure out the relationship between size of the blank image and capacity.



My procedure was to create a blank, non encrypted sparsedisk image in Disk Utility. I would then record the size in mb (i know bytes would have been better but i didn't need an exact correlation).



I repeated it 2 more times to make sure it wasn;t soemthing to do with background operation. I got the same exact data all times.



It was as follows:



Capacity (mb).........Empty Size(mb)

40....................10

150...................12

325...................23

1000..................33

5000..................30

12000.................34

25000.................37



Graphed it looks like





So it sort-of makes sense with the sizes except for 5000 and 1000. Why is a larger image smaller? Like i said, i did this three times and they both came out the the exact (as in exact bytes not just mb) same size.



I am compleatly confused. Can anybody sign some light on this and maybe do thier own test?



BTW, I am using 10.3.8 with a 1.0 Ghz PB (DVI) 768ram

Comments

  • Reply 1 of 7
    voltavolta Posts: 3member
    Unbelievable but true! I tried it and i got the same results. I think the graph should be calculated with more values since the correlation seams strange. In fact... this is not even a problem, thats why i'm too lazy to do a couple of sparse images to make the graph more accurate. Still, it's strange, maybe someone as an answer but i suggest it a misoptimization.
  • Reply 2 of 7
    jwink3101jwink3101 Posts: 739member
    I did not do a curve (or line) of best fit. That is just Excel Connecting the dots.



    Below is one with a logarithmic trendline:





  • Reply 3 of 7
    lundylundy Posts: 4,466member
    Maybe at 1 GB capacity the blocksize changes to 4KB pages instead of 512 bytes? This would mean fewer blocks to keep track of since each block is 8 times larger.



    Or it could mean I don't know what the hell I'm talking about.
  • Reply 4 of 7
    xoolxool Posts: 2,460member
    Quote:

    Originally posted by lundy

    Maybe at 1 GB capacity the blocksize changes to 4KB pages instead of 512 bytes? This would mean fewer blocks to keep track of since each block is 8 times larger.



    Or it could mean I don't know what the hell I'm talking about.



    I think you know what you're talking about. And my gut feeling is that you're right.
  • Reply 5 of 7
    jwink3101jwink3101 Posts: 739member
    Althouh i do not totally uunderstand what you are saying, i think you are definitly right.



    1050 mb.......26
  • Reply 6 of 7
    lundylundy Posts: 4,466member
    Quote:

    Originally posted by Jwink3101

    Althouh i do not totally uunderstand what you are saying, i think you are definitly right.



    1050 mb.......26



    That makes sense. I think Apple had to do this at some point when the HD sizes got over 1GB.



    They are still using 4KB though. Make a one-byte text file and look at it in the Finder and you will see that its size is 4K.



    32 bits can address 4,294,967,296 blocks. Times 4096, however many GB that is....
  • Reply 7 of 7
    xoolxool Posts: 2,460member
    Around the time HFS+ first came out, there were tools that would let you control the block size during a format. There was also a program to convert your drive to a smaller blocksize. (Alsoft's PlusOptimizer, or something.)



    I don't know if there's a similar tool we could use for disk images, but I bet if you could toggle on the large block sizes for small disks the anomaly would go away. You might even be able to force the small block sizes on the larger images and have two separate curves.
Sign In or Register to comment.