A Happy Problem - Running Out of Disk Space!

[Jim Manley]

Well, after a week of plinking along on the Pi in the UK I have remote access to from California, I finally got an error message that made me smile - "Insufficient disk space"!  You really know you're in software development bliss when you've forgotten the old days when we used to watch every single byte of core/RAM and drum/disk space consumed, and you see that kind of message.

It really is strange that, even with 2 GB of SD card space, there's only a few hundred MBs of space available to the user on the Debian variant, and it fills up fast if you're doing much in the way of development on the platform.  At that, I'm really just getting a feel for how things run in the limited resources of a Pi, but, I'm quite surprised and delighted to report that you can actually get some things done.  Of course, you wouldn't want to build anything complicated, but, for run-of-the-mill, typical, day-to-day command-line sorts of things, it's quite adequate.

The fact that I've been able to get work done for five days in a row without a crash has contributed to this happy problem.  I was in no danger of using up disk space when I kept having to set up my development environment every day.  Heck, I was hesitant to leave any window open, much less running anything in it, not knowing for sure whether memory was being exhausted, the power was unstable/insufficient, or some other issue was causing the crashes.

Anyway, fair warning if you plan on doing much of anything beyond the plain-vanilla things included in the Debian release (and there really is a lot there) - you're probably going to need a bigger boat, or at least one with more disk space!

[JeremyF]

Is there a way to install programs downloaded via apt-get onto an external drive? I never quite figured that out.

[rmm200]

Easiest solution is to start with a larger SD card. Install the 2GB image, then use the instructions in the wiki to expand to the full size of your card. Better performance solution is to move the rootfs to a usb device. Probably a forum reference for it. Then apt-get would install to the USB device.

[Jim Manley]

Of course, using a bigger SD card or adding storage via USB are the solutions, but, being 5,424 miles away from the Pi I'm working on, I don't quite have that option at the moment.  The major offenders here are in places like /var/cache/apt - once the .deb files have been used for installation, they can be archived off and deleted from the card, and only those need to archived that were added/updated since first bootup of the system - some are from the release itself and already archived within the release itself.

The only directory that must be on the SD card at bootup is /boot, everything else can be moved to one, or more, USB storage devices (flash RAM thumb drives, hard disk drives, etc.), and the configuration files in /boot need to be updated to point to the USB storage path(s).  Once the system is booted, /boot isn't even needed until the next bootup, and the SD card can be swapped out for others, providing even more storage.

It also appears that the SD card interface is operating much more slowly than expected based on card speed abilities, and it may be faster to run from USB storage anyway, rather than using a larger SD card.  I haven't seen a definitive response from the Foundation as to whether the SD card interface speed issue has been identified and whether there is anything that can be done about it, e.g., updating the driver.

[Lob0426]

I see the SD card bottleneck on a Panda Board also. It is recommended to transfer everything to a USB SSD or HDD. And leave the card for booting. Have not tried it yet. It should be able to be accomplished on the RasPi also. The problem is that you are using system files and pulling data from the SD at the same time. By separating them the system will be faster. For the people that want to run the RasPi as a media player, I believe they are going to quickly discover that their media will need to be off of the SD card. This has been true for the beagle boards and the panda boards also.
I used gparted to "grow" the partition on the SD cards. This was really slow on the netbook under Ubuntu. It was 8GB cards. Using windiskimager showed that the class 4 cards are only being written at a little over 5MB a second. The read is only about 10 to 15 MB/s I have tested USB HDD"s at 30 to 40 MB/s on USB 2.0. I learned very quickly yesterday to make two cards. Did in the first card trying to install OMAP addons. Had to start all over again. Hours worth of effort. Made two the second time.

It would be good to see some tests of the SD card and USB stick transfer rates. JamesH, I think did some on a Alpha board but I do not think anyone has tried it on the Production boards. Of course it will not be easy to find software for it that will work on a RasPi.

[HeadCase]

I have an 8G SanDisk Ultra SDHC card with the main Debian partion expanded to 3.5G and a GeneralPurpose 4G ext4 partition tacked on the end.

If I plug that SDHC card into a Desktop Linux PC via a USB Card Reader and run Disk Utilty RO Benchmark, it reports the read speed at 20MB/s (Seek Time 1mS).

RPi Debian 8G SDHC, 180G USB HDD

As an experiment I did a large data copy to/from an SDHC partition from/to an external USB HD partition - which would give the RPi SD drivers a severe workout.

Results:-

1. USB WD Passport HDD  ->  RPi ext4 Partion   (File is 494.6MB .mkv video file)

116secs  :- transfer rate = 494.6MB/116    =    4.26 MB/s

2.  RPi ext4 Partion  ->  USB WD Passport HDD  (File is 494.6MB .mkv video file)

77 secs :- transfer rate = 494.6MB/77        =   6.42MB/s

I know SD writes are quite slow, but what surprised me was that this copy operation maxed out the CPU usage for both transfers to and from the SD card. The read speed from the SD on RPi was well below the 20MB/s as reported possible with DU on a Big Iron desktop.

The SoC has a fairly powerful DMA capable controller for the SD card and the USB controller. I would have expected that for these data transfers the CPU load would be moderate as mostly it would be waiting on the DMA transfers to complete.

So, I guess the question is whether the current IO drivers are optimised, and if not, how much performance is ultimately feasible?

I would imagine that to see 3d apps perform well, low latency, low CPU overhead reads of assets from the SD card would be highly desirable.