ma...@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/ _______________________________________________ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss