|
|
Subscribe / Log in / New account

A mapping layer for filesystems

A mapping layer for filesystems

Posted May 10, 2018 9:31 UTC (Thu) by dgm (subscriber, #49227)
In reply to: A mapping layer for filesystems by ringerc
Parent article: A mapping layer for filesystems

First let me tell you that I don't have experience with large server pools.

That said, I fail to see how thin provisioning is better than allowing users to freely take more space as they need it.

By your explanation, it seems that it is used like some kind of pre-granted quota that you can use without explicit permission, but with the undesirable side effect of unexpected errors when resources that are supposedly there fail to materialize. That in turn forces complexity on the applications, because you cannot make assumptions.

If you want to have quotas, why don't you use quotas? Or is there some other reason?


to post comments

A mapping layer for filesystems

Posted May 10, 2018 10:38 UTC (Thu) by farnz (subscriber, #17727) [Link]

Thin provisioning moves the management overhead from the thousands or tens of thousands of VMs using the storage system, to the single storage system.

Instead of having to ask for space in small chunks (say 10 GiB at most), and having to expand regularly to cope on each of the VMs, you can give the VMs virtual disks that appear big enough for (say) 5 years worth of predicted use. The server admin only has to check in and ask for more space when they have new projections showing that they need much more space than they have has assigned.

In the meantime, though, you now have tens of thousands of machines that have enough space for the worst case 5 year projection; they're not going to need that up front, so you really don't want to buy that much disk space today, only to leave hundreds of disks empty. Instead, you thin-provision; each virtual disk is only allocated as much space on the real drives as it really needs today, and you set up monitoring so that you know when you're going to need more real disks and can order them in before you need them.

This means that instead of tens of thousands of server admins allocating 10 GiB chunks every couple of days, you have a small number of storage admins buying and bringing online disks every few weeks or months as needed for your growth. Your servers think they have 500 PiB of space between them, but you've only bought 200 TiB so far, and bring another 10 TiB online whenever you run low on used disk.

If it all works as designed, thin provisioning is completely transparent to the clients - you always have more real disk than you're using, so the impact of thin provisioning is that you neither buy a huge amount of otherwise idle disk nor have to keep allocating space to the servers that need it. You just wait for the storage array to run low, then add another chunk.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds