My retropie setup (latest 3.5 version on jessie) is showing 0 available space even though I haven’t used all the blocks. When typing “df” at the command line it shows this:

Filesystem    1k-blocks    Used        Available    Use
/dev/root     59455228     57517592            0    100%

The filesystem has already been expanded to its full capacity (its a 64GB card). I thought it was maybe just a visual error but it won’t let me copy any new files since it thinks I’m out of space. If I delete a file the Available space still remains at 0, but the Used space will go down. When I take the sdcard out and plug it into my ubuntu machine it shows 1.86GB available on the card.

  • Did you use raspi-config to expand the filesystem? Commented Feb 27, 2016 at 3:44
  • Yes. As mentioned its been expanded to its full capacity of 64GB.
    – alduin
    Commented Feb 27, 2016 at 3:58

2 Answers 2


You may want to glance over this exhaustive explanation of some issues from U&L.

In short, this is normal and you'll see the same discrepancy on any default formatted ext filesystem. For example, here's something from a ~150 MB partition on my laptop:

Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda7      149290292 13884224 127799440  10% /

If you do a little math here, however, you'll notice 149290292 - 13884224 = 135406068, not 127799440, a difference of 7606628 blocks, i.e., ~5% of the partition.

This is because when the filesystem is formatted, 5% of the space is reserved for the root user only. The purpose of this is to leave a bit for use in emergency recoveries.

This is not generally considered wasted space, however, since filling any filesystem beyond 70-80% -- unless the intended purpose of that filesystem is exclusively long term static storage -- will result in serious performance degradation, so by the time you hit 90-95% you've might have already made a big mistake.

Or not, because the logic behind that I think is mostly to do with traditional spinning disks, where the more of the disk is used, the harder it is to prevent fragmentation, and the further the disk head may have to travel to get the bits and pieces of various files. The effects of fragmentation do not apply to solid state hardware such as SD cards. Although some of their own peculiar characteristics (having to do with erasing and re-writing entire blocks of a certain surprisingly large minimum size) may create a similar problem, I couldn't find any benchmarks to confirm or deny this, but I did not look very hard.

Do note that the percentage use of an SD card, however, will directly relate to its lifespan, because they have an internal controller that will spread stuff around to average the wear (wear leveling); obviously if the card is full this is not likely possible, and if you are using it as a root filesystem and the life cycle of a given segment is only 1000 uses, you may end up with corruption happening sooner rather than later.

You might consider moving some stuff to a USB stick, which is also likely to be a bit faster since the SD card reader is limited to 20-25 MB/s.

Anyway, to double check how many blocks actually were reserved for the purpose described above:

sudo dumpe2fs -h /dev/mmcblk0p2 | grep "Reserved block"

The grep pipe at the end is just because that command spits out a fair bit of other information. Finally, you should be able to change the percentage with, e.g.,

sudo tune2fs -m 1 /dev/mmcblk0p2

Will reduce it to 1%. This all presumes /dev/mmcblk0p2 actually is the partition.

Both those programs are in the e2fprogs package (on Raspbian) but I believe it will already be installed.

  • Is there a way to override this and get access to the extra space?
    – alduin
    Commented Feb 27, 2016 at 6:13
  • It's odd because my previous setup was an 16GB card and it let me go all the way to 100% if I wanted and I was pretty close to the end. The card became corrupt so this could very well be why it died. So I should never go above 80% then?
    – alduin
    Commented Feb 27, 2016 at 7:05
  • I think you've actually gone beyond 95% there, so it could be that retropie sets things up this way to start with (I don't know much about it). My thinking about this WRT to SD cards might be a bit off; I've edited the answer here quite a bit to reflect that (see in particular "Or not...") and made some suggestions about how you can check and change the reserved block percentage.
    – goldilocks
    Commented Feb 27, 2016 at 11:23
  • So I tried what you suggested with moving some stuff to a USB stick and I find it's actually slower than the SD Card. It's a USB3 drive which has about 140MB/s read when connected to USB3 on my computer, but it should still be able to get the max USB2 speed (~60MB/s) on the pi, no? Do I need to do anything to increase the I/O speed of the USB controller on the pi?
    – alduin
    Commented Feb 27, 2016 at 21:10

You can try resizing the partition manually. See the elinux docs for this.

Basically, you write a new partition table manually with:

sudo fdisk /dev/mmcblk0

Then using:

sudo resize2fs /dev/mmcblk0p2

to apply the new partition table.

I would also try reinstalling the OS or trying a different SD card if possible, to see if the problem lies with the Pi, the card, or the OS.

  • I'll give that a shot but the card already appears to be using the full amount, otherwise wouldn't it show with 0 space in ubuntu as well? Gparted on Ubuntu shows me 1.8GB remaining on the partition. I don't have another 64GB handy to try and see if it's the card but I did an integrity check on the card before installing which passed with no issues.
    – alduin
    Commented Feb 27, 2016 at 4:25
  • @alduin unexpanded cards on raspbian usually don't show 0 GB when looked at from other computers. They usually show a few hundred MB, possible up to one GB. Those are usually 8GB cards, so it would make sense that your card shows about 2GB. Commented Feb 27, 2016 at 4:27
  • I resized the partition manually but nothing changed. It was already at the end since I did the auto resize when I first installed retropie.
    – alduin
    Commented Feb 27, 2016 at 6:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.