2011-11-23 7:39, Matt Breitbach wrote:
So I'm looking at files on my ZFS volume that are compressed, and I'm wondering to myself, "self, are the values shown here the size on disk, or are they the pre-compressed values". Google gives me no great results on the first few pages, so I headed here.
Alas, I can't give a good hint about VMWare - which values it uses. But here are some numbers it might see (likely "du" or "ls" sizes are in play): Locally on a ZFS-enabled system you can use "ls" to normally list your files. This would show you the logical POSIX file size, including any referenced-but-not-allocated sparse blocks (logical size = big, physical size = zero), etc. Basically, this just gives a range of byte numbers that you can address in the file, and depending on the underlying FS all or not all of these bytes are backed by physical storage 1:1. If you use "du" on the ZFS filesystem, you'll see the logical storage size, which takes into account compression and sparse bytes. So the "du" size should be not greater than "ls" size. Harder to see would be the physical allocation size, which refers to your data pool's redundancy (raidzN level, copies=N and so on). But you can more or less calculate that from "du" size. Also your files on ZFS indirectly consume space by requiring some metadata blocks (usually one per data block, and usually they are comparatively small) which is pool metadata and does not show up easily as "file size" as well. If you're too interested, you might search for howtos on "zdb" command usage to "debug" your ZFS pool and gather stats. If your new storage system does support some sort of compression, at least for contiguous ranges of zero-bytes, you might write some large zero-filled files into your VM's filesystems. This should empty the blocks previously used by files now deleted in the VM and may give temporary space savings.
This really relates to my VMware environment. I had some "things" happen on my platform that required me to Storage Vmotion everything off of a particular zpool. When I did that, I saw most VM's inflate to nearly their thick provisioned size. What didn't swell to that size went to about 2/3 provisioned (non-Nexenta storage). I have been seeing 1.3-1.5x compression ratios on pretty much everything I turn compression on for (these are general use VM's - webservers,SQL,firewall,etc). My question is this - when I'm looking in the file structure, or in the datastore browser in VMware, am I seeing the uncompressed file size, or the compressed filesize? My gut tells me that since they inflated _so_ badly when I storage vmotioned them, that they are the compressed values, but I would love to know for sure. -Matt Breitbach
HTH, //Jim Klimov _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
