I'm a new customer coming over from Amazon AWS where I ran an Ubuntu v13 instance. I have a Debian 7 server here. I'm trying to install the postgresql package like this:

sudo apt-get update
sudo apt-get upgrade --show-upgraded
sudo apt-get install postgresql

When I run these commands, I get this error message:

Reading package lists…  Done
Building dependency tree
Reading state information…  Done
You might want to run ‘apt-get -f install’ to correct these:
The following packages have unmet dependencies:
postgresql : Depends postgresql-9.1 but it is not going to be installed

Now as I understand it, the advantage to using APT to install a package is that it will automatically install any dependent packages for you. On my EC2 instance, I could run the same commands as above and APT there would install all of postgresql's dependencies as well as postgresql itself.

Why doesn't APT on Debian install postgresql? Shouldn't it work the same here since Ubuntu is an offshoot of Debian?

Thanks!

I fixed this. There were two problems:

1. I had some broken dependencies.
2. My root disk was full so I couldn't run "sudo apt-get -f install" to repair the broken dependencies.

Solution:

1. Create a new disk partition for /usr so I had room to install missing packages.
2. Run "sudo apt-get -f install" to fix the broken dependencies. This entailed installing the missing packages.

Are you sure you want to be splitting up your linode's storage into different partitions? There's no benefit to doing so unless you plan to swap them around frequently.

Well, the default partition size is, I believe, only about 776 MB which is too small to hold my web site. /usr alone is about 500 MB and when I tried to install some needed packages, the main disk filled up. There's also /var which will grow over time. To me it made sense to create separate partitions for usr, var, home, and www.

Perhaps I'm missing something. What do you suggest?

Thanks.

I prefer to have one big partition for / (at least 4GB), one 256MB partition for swap (this is the default I think), and maybe a third partition for /var if I expect its size to grow a lot. But that's about it. I rarely use a fourth partition nowadays.

Debian places both the web root and the MySQL data storage under /var by default, along with all the logs and other stuff that "varies" over time. So /var is the only partition that really grows over time unless you have your web root under /home or some other path. Besides, a lot of web apps don't grow in size at all

It's also ridiculously easy to resize disks here, since all disks are virtual. With a physical disk in a physical server, you have to move partitions around if you want to resize anything in the middle, so it's important to get all the sizes right the first time. With virtual disks, it doesn't matter. If one of your disks grows too large, you can easily redistribute storage among your disks or upgrade your Linode for more storage. It only takes a few minutes and a reboot, which is nothing compared to the hassle of resizing partitions on a physical server.

Finally, this isn't EC2/EBS. Unless something has changed with the recent per-hour billing announcement, you don't get any discount for unallocated disk space. So it's best to allocate all the space that comes with your Linode. There's no reason to have a root partition smaller than a couple of GB's when you have 48GB or more to play with.

Hybinet, what you said makes sense. Back in the nineties when I was a Unix sys-admin, we'd put different directories on different partitions because this would allow the disk controller to access multiple partitions at the same time and thus speed up performance. I'm guessing that with virtual disks that analogy no longer holds true? With virtual disks, does it not take any more time to access three different directories on the same partition as it would if they were on three different partitions? Thanks.

I think this falls under the category of "things that Linode doesn't want you to care about". How the disks are provisioned is an implementation detail that can change at any time, especially since they've been experimenting with SSDs lately. You have zero control over the physical location of your disk images on the actual platters.

Anyway, I'm guessing that there won't be a huge difference between one partition and multiple partitions because everything resides on the same RAID 10 array. Any difference will probably be due to how the kernel handles filesystems. But you could run some benchmarks if you're really curious

I don't believe its been true with real hard disks since the 90s either. Multiple partitions would reduce performance, if anything, by forcing additional seeking.

Agreed, I did the multiple partition thing once back then, the performance was bad. Fortunately RAID for the average consumer eventually came along and we could go back to one big partition or two.

Oh and the two times I really needed my expensive tape backup to work...it didn't. rsync and RAID or even just rsync saves the day.