[Discuss] Thin Provisioned LVM

[tmetro+blu at gmail.com (Tom Metro)]

markw at mohawksoft.com wrote:
> Consider this: You are a large cloud hosting company. You have a SAN
> storage system from which you allocate thin provisioned virtual luns which
> you then present to ESX server virtual machines. You give each customer a
> 2T LUN on which to install their OS of choice. The customers are billed by
> the actual amount of storage they use. Using a conservative allocation of
> disk space and in-place modification, the hosted system doesn't grow on
> the LUN.
> [...] 
> The problem with ZFS, is that it is very aggressive at growing the pool.
> It assumes there is no cost to using the whole disk. Once it writes to a
> block, that block is pulled out of the SAN and allocated to the LUN, you
> can't give it back in the SAN. The number of "used" blocks have not really
> changed on the LUN, only more free space has been allocated to it. Now the
> customer has to pay for that and the hosting company has to add more
> storage to their SAN.

Are you talking about the behavior where a file occupies blocks A, B,
and C, then the portion residing in block C gets modified, but instead
of it being overwritten, a new block D gets written, and the current
file index updated to point to blocks A, B, and D?

If so, isn't that behavior a necessity for the snapshot capability in
ZFS and fundamental to its design?

According to this rather high-level (superficial) description of storage
allocation:
http://docs.oracle.com/cd/E19253-01/819-5461/gbchp/index.html

it sounds like as long as you don't have a snapshot pointing to block C,
it will eventually get reused. But it doesn't say when.

I guess you might see the same behavior in other file systems, but
you're saying with ZFS it doesn't go back to reuse block C until the
disk starts to fill up?

 -Tom

-- 
Tom Metro
The Perl Shop, Newton, MA, USA
"Predictable On-demand Perl Consulting."
http://www.theperlshop.com/