1 |
Alec Ten Harmsel <alec@××××××××××××××.com> writes: |
2 |
|
3 |
> On Tue, Jan 19, 2016 at 10:56:21PM +0100, lee wrote: |
4 |
>> Alec Ten Harmsel <alec@××××××××××××××.com> writes: |
5 |
>> > |
6 |
>> > Depends on how the load is. Right now I have a 500GB HDD at work. I use |
7 |
>> > VirtualBox and vagrant for testing various software. Every VM in |
8 |
>> > VirtualBox gets a 50GB hard disk, and I generally have 7 or 8 at a time. |
9 |
>> > Add in all the other stuff on my system, which includes a 200GB dataset, |
10 |
>> > and the disk is overcommitted. Of course, none of the VirtualBox disks |
11 |
>> > use anywhere near 50GB. |
12 |
>> |
13 |
>> True, that's for testing when you do know that the disk space will not |
14 |
>> be used and have no trouble when it is. When you have the VMs in |
15 |
>> production and users (employees) using them, you don't know when they |
16 |
>> will run out of disk space and trouble ensues. |
17 |
> |
18 |
> Almost. Here is an equal example: I am an admin on an HPC cluster. We |
19 |
> have a shared Lustre filesystem that people store work files in while |
20 |
> they are running jobs. It has around 1PB of capacity. As strange as this |
21 |
> may sound, this filesystem is overcommitted (we have 20,000 cores, |
22 |
> that's only 52GB per core, not even close to enough for more than half a |
23 |
> year of data accumulation). Unused data is deleted after 90 days, which |
24 |
> is why it can be overcommitted. |
25 |
|
26 |
Why do you need to overcommit in the first place when you don't need |
27 |
that much disk space anyway? And it only works because you "shrink" the |
28 |
disk space used by deleting data. |
29 |
|
30 |
> Extending this to a more realistic example without automatic data |
31 |
> deletion is trivial. Imagine you are a web hosting provider. You allow |
32 |
> each client unlimited disk space, so you're automatically overcommitted. |
33 |
> In the aggregate, even though one client may increase their usage |
34 |
> extremely quickly, total usage rises slowly, giving you more than enough |
35 |
> time to increase the storage capacity of whatever backing filesystem is |
36 |
> hosting their files. |
37 |
|
38 |
I'm a customer of such a provider that used to do that, and they stopped |
39 |
giving their customers unlimited disk space years ago. I guess they |
40 |
found out that they can't possibly keep up with the demand, at least not |
41 |
without charging more. |
42 |
|
43 |
>> > All Joost is saying is that most resources can be overcommitted, since |
44 |
>> > all the users will not be using all their resources at the same time. |
45 |
>> |
46 |
>> How do you overcommit disk space and then shrink the VMs automatically |
47 |
>> when disk usage gets lower again? |
48 |
>> |
49 |
> |
50 |
> Sorry, my previous example was bad, since the normal strategy is to |
51 |
> expand when necessary as far as I know. See above. |
52 |
|
53 |
Well, that's exactly the problem. Once a VM has grown, it won't shrink |
54 |
automatically, which soon breaks the overcommitment. |