Disk space vs. distro size

Hello Mike,

You are correct.

The mnimum size for each distro smallest you can create a disk image for it. Installing with the minimum size would only leave a few megabytes free inside that filesystem.

The storage space allows you to create as many virtual disk images as you can fit.

Since you only need one install, you would want to use the Distro Wizard and set the maximum size you can (for example 1GB) for your new install. The difference between your Distro's minimum size and the size you make the image will determine the amount of free space.

All of our distros are un-tainted package-based installations, so it's fairly easy to use "rpm" or "apt-get" to remove un-needed things.

You're probably not going to miss much from the larger installs if you're intending on running a few internet services.

Thanks for your questions!

-Chris

Thanks for the prompt reply. Yep, apache/php/qmail are all that I really want to run. I will probably go ahead with the Linode 128, however, for the extra space and ram.

BTW: The Linode hosting concept is really cool. Good idea.

… Mike

I don't understand why you would be using Usermode Linux and not be using the COW file format for the base distros. I'm sure you're aware, but for those who don't know, this would allow user's to have the full free amount of disk space and only changes to their virtual environment would cause virtual disk shrinkage. Since likely 95% of the base distribution would be left unchanged, this would give the users orders of magnitude more useable harddrive space.

I'm not a customer, but I am thinking about it. This would be one of my deciding points. Any comments?

Sure – a few things…

With COW (Copy On Write), someone could still delete everything on a disk and replace it, but now I've got the size of the backing file(s) and the COW(s). The problem here is that the total size is somewhat unpredictable, from an administrative point of view.

Secondly, the backing files aren't easily migratable -- the COW files themselves won't mount if you don't have the exact backing file that was used when it was "created".

I just felt better about making things more simple. Less to go wrong with COWs and whatnot. The only advantage I've seen to COW would be a "snapshot" feature which you could restore to in a second. But, the next snapshot (new COW) would require a merge of the existing backing file and the old COW, which would mean downtime.

Thanks,

-Chris

> The problem here is that the total size is somewhat unpredictable, from an administrative point of view.

I don't agree, though of course I don't work there. ;) However, just looking at it, you would still have the same amount of predictability with COW since each user would still be allocated his/her allotment of disk drive and you would know how much each distro takes up.

In fact, you would considerably save on harddrive space since most users would then never use their full potential of space. In theory you could over subscribe your harddrive space and just add to your raid when it starts to get full.

This obviously benefits users as well since now they've got a bunch more space to work with. Nice for power users, etc. It would give you a whole lot more room to offer various packages as well (offer 200MB, 500MB, 1GB, 1.5GB, etc.).

> Secondly, the backing files aren't easily migratable – the COW files themselves won't mount if you don't have the exact backing file that was used when it was "created".

Yes, but again, this should never be a problem. I mean, once a virtual environment is created, you don't go in and change the user's base distribution anyway. You would leave it up to the end user to do so. (ie. applying patches, errata, etc. to their distro).

With COW, yes you would have to maintain all the backing files pretty much forever (or until no more customers used them), but I can't imagine this being that big of a deal.

> The only advantage I've seen to COW would be a "snapshot" feature which you could restore to in a second.

Yes, again another very strong point to using it.

> I just felt better about making things more simple. Less to go wrong with COWs and whatnot.

Yes, it's like a bit easier to deal with in the way you describe.

I'm not flaming here or anything. I'm just playing a bit of devil's advocate. Mostly, I want the harddrive space. I think your harddrive pricing is a bit higher than other quality virtual providers. I like what you're doing and I like the usermode linux project a lot. But, without COW, I'd have to think hard about jumping on. With in, I'd probably give you my credit card today.

Thanks again for discussion.

I would go with the small Debian distribution if I were you. After adding what you need, you'd probably not reach even 150 MB. Debian is also known for its reliability and it's an excellent distribution for servers. Using 'apt-get', installing new packages is as simple as typing, say, 'apt-get install wget', and upgrading the entire system is as easy as typing a few apt-get commands.

@mikebryant:

I am considering a the Linode 64 package for my ultra-small business. My question is this: if the Linode 64 comes with 1 GB of storage and I install the small installation of Slackware 9.0, there will be ~550 MB of user space available, right? And since the large install of Mandrake requires ~1.3 GB I couldn't install it at all as there wouldn't be enough disk space available. Is this correct?

I just want to make sure I know exactly what I'll be getting if I decide to go this route.

Thanks,

Mike

How about making the most important utilities (compilers etc) available on a host OUTSIDE the user's virtual host, so the user can NFS mount it or something like that. No need for COW. Those files would be read-only to the user. The user can set up his exec path to override the NFS mount if he wants to run his own version of gcc or something like that.