win32diskimager not enough space

Hello,

sorry but it is not so clear what you need. If you are trying to burn a 8Gb (about) image on a microSD of the same size without formatting it you will see that there is not enough space on it. The burn process does not include media formatting, so  - depending on the OS you are using - there is a procedure. What the program burning images on SD and microSD usually expect is to have a enpty, FAT32 formatted card.

Enrico

What I understand is that VT wants to create an image of his 8Gb SD card and write it back. Now to the exact same SD card it came from, but maybe later to a different SD card.

I once had a card that would "shrink" by a few bytes every time you used it. This would continue until it was smaller than 4Gb then it would remain the same size.....

VT, You are right: normally it should be possible to image a card and then write it back. One  thing that I notice is that your image is more than 8 billion bytes. Many harddisks and SD cards would say 8Gb and then be 8000000000 bytes. Maybe a FEW more, but not 68 megabyte.

Um do you have a Linux install you can use ?

In that case you can use "dd" to create and write the saved image.

You shouldn't get the same problems reading and writing even if something is "shorter" , I suspect that the program is appending some data to the end to pad it out !

John

John is on the correct path. See SD Image won't fit on SD Card - Raspberry Pi Stack Exchange which explains in more detail. The problem is data can be deleted yet still exist on the card. Win32diskimager will copy even this. Note you expanded that as well using sudo raspi-config. This creates the largest possible file system. That could create some padding at the end that Linux can handle. But Windows utility cannot realize and wants to allocate them causing just a bigger image. The answer is to shrink. BTW, did you reformat the card? This could change the sector size and indicate less room than before. Try to reformat with 512 byte sector. Contrary to what may be expected, a 1024 may have better fit. The logic here is the space between sectors is fixed and wasteful. So fewer spaces is better to some degree.

Clem

Clem, sector size on modern Multi level flash chips is 4k. In the old days with single level cells, you'd have most sectors containing about 0 errors. Then there was the ECC that could correct the occasional bit flip and even two or three flipped bits just to be sure.

However, modern MLC chips end up with an average of around 4 bit flips for every sector (on the one chip where I tested all this) . To reliably fix that, you need a much bigger amount of ECC. Increasing the sector size, with the proper ECC will improve reliabilty. If you start out with say x bytes of ECC per 512byte block and then move to 2x bytes for a 1024 byte block, if the original could fix 10 bit flips then the 2x bytes in a 1024 byte block will be able to handle almost 20 bit flips. So the bigger chunk can easily handle say 15 bit flips, even when they are all in the first 512byte block, while the original could only handle 10 bit flips in any one sector.

So, physical sector sizes are 4k nowadays. Both on harddrives and SD cards.

All this ECC stuff is hidden from the computer at the SD card interface. There is no way you can "format" an SD card with 512 or 4096 byte sector size from the computer. The SD card presents "an array of 512 byte sectors" to the PC. Even if the internal physical structure has 4k sectors the standard requires it to handle 512byte blocks.