Different sizes between zfs list and zpool list
fjwcash at gmail.com
Wed May 5 16:36:23 UTC 2010
On Wed, May 5, 2010 at 9:28 AM, Freddie Cash <fjwcash at gmail.com> wrote:
> On Wed, May 5, 2010 at 9:20 AM, Tom Evans <tevans.uk at googlemail.com>wrote:
>> On Wed, May 5, 2010 at 4:56 PM, Freddie Cash <fjwcash at gmail.com> wrote:
>> > On Wed, May 5, 2010 at 8:44 AM, Tom Evans <tevans.uk at googlemail.com>
>> >> When looking at the size of a pool, this information can be got from
>> >> both zpool list and zfs list:
>> >> > $ zfs list
>> >> NAME USED AVAIL REFER MOUNTPOINT
>> >> tank 5.69T 982G 36.5K /tank
>> >> > $ zpool list
>> >> NAME SIZE USED AVAIL CAP HEALTH ALTROOT
>> >> tank 8.14T 6.86T 1.28T 84% ONLINE -
>> >> Why the different sizes?
>> >> The pool is a raidz of 6 x 1.5 TB drives.
>> > zpool lists the raw storage available to the pool. Every single bit of
>> > every single drive is listed here. This will be 6 x 1 TB.
>> > zfs lists only the amount of storage available to be used, after all
>> > redundancy is taken into account. This will be 5 x 1 TB.
>> Ah, that makes sense - also explains why the df output matches up
>> precisely with the zfs list output.
> Things get really interesting once you enable compression on a filesystem,
> as then du, df, and zfs list will all be different. :)
> There's a great post on the zfs-discuss mailing list that covers this.
> I'll see if I can dig it up.
>From a message by Will Murnane to zfs-discuss (in response to Harry Putnam):
On Sun, Apr 18, 2010 at 20:08, Harry Putnam <reader at newsguy.com> wrote:
> Seems like you can get some pretty large discrepancies in sizes of
> pools. and directories.
They all answer different things, sure, but they're all things that an
administrator might want to know.
> zpool list
"How many bytes are in use on the storage device? How many
unallocated bytes are there?"
> zfs list
"If I have to ship this filesystem to another box (uncompressed and
not deduped) how many bytes is that?"
"How many bytes are used to store the contents of the files in this
and "ls -l":
"How many bytes are addressable in this file?"
> Do no other administrators feel the
> need to know accurate sizes?
It's important to consider what you want this data for. Considering
upgrading your storage to get more room? Check out "zpool list".
Need to know whether accounting or engineering is using more space?
Look at "zfs list". Looking at a sparse or compressed file, and want
to know how many bytes are allocated to it? "du" does the trick.
Planning to email someone a file, and want to know if it'll fit in
their 10MB quota? "ls -l" is the relevant command.
In short, there are many commands because there are many answers, and
many questions. No single tool has all the information available to
zpool shows the total bytes of storage available in the pool.
zfs shows the total bytes of storage available to the filesystem, after
redundancy is taken into account.
du shows the total bytes of storage used by a directory, after compression
and dedupe is taken into account.
"ls -l" shows the total bytes of storage currently used to store a file,
after compression, dedupe, thin-provisioning, sparseness, etc.
fjwcash at gmail.com
More information about the freebsd-stable