Thin provisioning doesn't fix this problem. At least not today.
The only way thin provisioning fixes this problem is if you over-commit the thin pool. That's all well and good, but currently, any given storage chunk that is allocated to a server is stuck being allocated to that server. So, if I were a server admin who found out he'd been given thin LUNs in an over-commited pool, I know that if my neighboring admins don't keep track of their storage use, then my server could wind up crashing because they took up all the storage. So instead, I'm going to write a script first thing when I get the storage to write a text file clear across the drive. There. Now my disk is fully provisioned, and my neighbors can use all the pool they want, it won't affect me. 'course, not everyone can do that, or the pool will fill up lickety split.
Now, someday, the servers will be smart enough to tell the storage array when they're done with a chunk of storage. At which point, that part of the pool can be freed up. When that happens (and it will, but it's going to take some time), thin pools will be ideal. Everyone will have all the storage they need almost all of the time.
However, that day isn't here yet. In the mean time, there are interesting performance reasons to use thin provisioning, but not space-related ones.
We did this ages and ages ago.
I graduated high school in '94, and we didn't have D grades then, and they still don't have them now in any district I know of.
Slashdot Mirror
They pay people a hell of a lot more than that to do middle-management work.
To be fair... it does make some sense that these two things would chase each other around in circles.
I just patched an SAP server last week that hadn't been offline since early 2010.
I wasn't patching SAP.
No awareness of timezones whatsoever.
It's going to be 6:30 in California, people!
Sheesh, if you want people to watch your announcement live, you need to schedule it when as many folks as possible are AWAKE.
Thin provisioning doesn't fix this problem. At least not today.
The only way thin provisioning fixes this problem is if you over-commit the thin pool. That's all well and good, but currently, any given storage chunk that is allocated to a server is stuck being allocated to that server. So, if I were a server admin who found out he'd been given thin LUNs in an over-commited pool, I know that if my neighboring admins don't keep track of their storage use, then my server could wind up crashing because they took up all the storage. So instead, I'm going to write a script first thing when I get the storage to write a text file clear across the drive. There. Now my disk is fully provisioned, and my neighbors can use all the pool they want, it won't affect me. 'course, not everyone can do that, or the pool will fill up lickety split.
Now, someday, the servers will be smart enough to tell the storage array when they're done with a chunk of storage. At which point, that part of the pool can be freed up. When that happens (and it will, but it's going to take some time), thin pools will be ideal. Everyone will have all the storage they need almost all of the time.
However, that day isn't here yet. In the mean time, there are interesting performance reasons to use thin provisioning, but not space-related ones.
We did this ages and ages ago. I graduated high school in '94, and we didn't have D grades then, and they still don't have them now in any district I know of.