OSNews

static666,

"The more important feature of thin provisioning is that pool space is allocated on the fly to the individual volume requesting it."

To be honest I'm not sure what benefits the "thin provisioning" has to offer over logical volumes.

Certain file systems can already be dynamically expanded as needed without overcommitting them in the first place. The existing data + structures can be used as is within an ever larger volume. This way, no fs re-formatting is needed, just appending more space to the end (LVM is perfect for this).

Unless there is a limitation of the NTFS at play, I'm uncertain why microsoft would chose the overcommitment implementation described since it offers no discernible advantage over a file system that can grow dynamically over it's lifetime.

Another question: Can the pool's size limit ever be changed or is it a hard limit until the whole pool is reformatted?


"It certainly won't panic. Ever tried to add a swap file with holes in Linux? It simply won't allow this. You have to allocate every 0 of it to a real storage."

I wasn't really talking about swap, linux routinely overcommits memory, but the scenario here is a bit different with disk space.

What happens when overcommitted disk resources run out? Windows ought to return an error, but sometimes, as with memory mapped files, that can be tricky to handle. I don't really know what windows does then.

Edited 2012-01-11 08:45 UTC