MojoDB Partition Resize

Introduction

If you use your webOS device frequently, you have probably encountered the "Application database full" error, and were confused by it. It is a very confusing error, and the remedies are equally confusing. The error suggests deleting data, but it isn't clear what data. I learned that it meant app data (such as emails, contacts, calendar events), and not media. Though, the amount of files that you have on your USB partition can play a factor, too. Unfortunately, the tricks to get this error to go away are very few and short-lived. As a result, you will be greeted with the next evil error. That error will force you to reset your device. In this process, you are required to sign back into your Palm profile and watch in horror as all of your apps re-download, all of your Preware apps gone, as if you got the device new.... Nasty.

Well, there is a solution (and no, I won't be trying to sell you some anti-aging cream, or miracle spray, so rest assured, I have tried this on my own Pre3).

The Dirty Bits

webOS 2.0 came along and offered a new application data storage feature. It allowed you to store data in a database called db8. It is pretty magical, and allows apps to share data through permissions. But, this feature had one fatal flaw. It was placed on its own isolated partition. This is a great way to protect the data, to some extent, but it limits how much data you can have on your device. The partition is only 135MB in size... You can use that quickly if you have a ton of files on your USB partition (the media indexer uses this database to store the index of the files on the USB partition), a few email accounts syncing regularly and storing a large backlog, and Koto Player indexing your media... This partition is /var/db... We will resize it.

Notes

There are three partitions of interest in the webOS world that can hold some valuable data. There is /var/db (the application data store), /var/file-cache (this stores a cache of contact pictures, email attachements, and a few other things, but is generally less important), and /var itself. The one we will focus on now (that causes the most trouble) is /var/db. Later I may add notes to changing the sizes of the others.

FAIR WARNING

I have seen people on the webOSNation forums recommend deleting large text files from the /var/db partition that do not have a ".db" extension. DO NOT (let me repeat that DO NOT) delete these files. They are database journal files. A journal is a small record of entries written to a database or filesystem that a data management system can look to in the event that it is abruptly and uncleanly shutdown. It allows the device to "replay" transactions (so to speak) if you, say, were to pull the battery because the device seemed frozen. Deleting these files can put the journal and database out of sync, and the results of that are pretty messy and require a few hours of patient database cleanup....

Pre-Operation Warnings

As should always be noted, there is always a chance that something could go HORRIBLY wrong. As a result, I provide absolutely NO warranty of any kind. You are on your own. As always, backup your data (using whatever process makes you feel the most secure, whether it is just copying off a few beloved photos, or doing a full mem dump).

I have only tested this on webOS 2.2.4 on a Pre3. It should work on any webOS 2.0+ device (likely including a TouchPad). If you do this on some other type of device, please report back!

Let's Go!

Basically, what you will do is shave some space off of your /media/internal partition, and hand that over to the application database. I went safe and did about 500MB for mine. "Memory is cheap", so why not? I'll give you the commands below.

You can check your current usage with this command:

df -h

I recommend getting your current usage (-h means "human"), then subtract about 512MB from it and use that number below when shrinking the media partition (My media partition was about 12.8G, so I just made it 12.2G, which gives me about 600MB available, and I enlarged my mojodb partition by 512MB, so I'll have a few MB leftover, which is fine since you may have to grow /var later on). Make sure that you have enough room to shrink your media partition! I recommend backing it up, and deleting anything to clear space if you need to.

## Shrink the media partition

# Need to stop the cryptofs process, or rather "pause" it
pkill -SIGUSR1 cryptofs

# Unmount the /media/internal partition
umount /media/internal

# Shrink the partition (Replace 12.2G with the amount of space you want to reduce to. I think that the partition is 12.8 by default?)
resizefat -v /dev/mapper/store-media 12.2G

# Reduce the logical volume (make the "physical" disk smaller) 12.2G is the **SAME** number as above.
lvreduce -L 12.2G /dev/mapper/store-media

# Remount
mount /media/internal

# Restart the cryptofs service
pkill -SIGUSR2 cryptofs

## Increase the Application Database

# Stop the MojoDB service
/sbin/stop mojodb

# Unmount the filesystem
umount /dev/mapper/store-cryptodb

# Extend the file system up
lvextend -L 512M /dev/mapper/store-mojodb

# Extend the encrypted size up
cryptsetup resize /dev/mapper/store-cryptodb

# Resize the underlying filesystem
resize2fs -f -p /dev/mapper/store-cryptodb

# Remount
mount /dev/mapper/store-cryptodb

# Restart the service
/sbin/start mojodb

It might be worth rebooting here, too. df -h should show that you have a roughly 512MB /var/db. The application database error should be in your past. :) The only time you may experience a serious error about the application database is if it happens to become corrupt...

Further reading

If you are resizing your Partition like this you will most lickaly run into this problem next DB_quota_exceeded, so for awareness it could be worth reading that page too.

Future Looking

My goal is to add this feature to Tailor. What I really am considering is setting up the partition like /media/cryptofs. If you notice, it shares the same size attributes as /media/internal. That is because they are the same partition! /media/cryptofs is actually a special cryptofs partition ontop of /media/internal. I would think that one could do this to /var/db, too. This would give one the most flexibility over application installation, data storage, and media space.