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

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 -

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

-Matt Breitbach
//Jim Klimov

zfs-discuss mailing list

Reply via email to