zfs raidz overhead

Andriy Gapon avg at FreeBSD.org
Thu Feb 23 07:27:36 UTC 2017


On 23/02/2017 02:49, Eric A. Borisch wrote:
> On Wed, Feb 22, 2017 at 3:50 PM, Wiktor Niesiobedzki <bsd at vink.pl> wrote:
> 
>> I can add to this, that this is not only seen on raidz, but also on
>> mirror pools, such as this:
>> # zpool status tank
>>   pool: tank
>>  state: ONLINE
>>   scan: scrub repaired 0 in 3h22m with 0 errors on Thu Feb  9 06:47:07 2017
>> config:
>>
>>         NAME               STATE     READ WRITE CKSUM
>>         tank               ONLINE       0     0     0
>>           mirror-0         ONLINE       0     0     0
>>             gpt/tank1.eli  ONLINE       0     0     0
>>             gpt/tank2.eli  ONLINE       0     0     0
>>
>> errors: No known data errors
>>
>>
>> When I createted test zvols:
>> # zfs create -V10gb -o volblocksize=8k tank/tst-8k
>> # zfs create -V10gb -o volblocksize=16k tank/tst-16k
>> # zfs create -V10gb -o volblocksize=32k tank/tst-32k
>> # zfs create -V10gb -o volblocksize=64k tank/tst-64k
>> # zfs create -V10gb -o volblocksize=128k tank/tst-128k
>>
>> # zfs get used tank/tst-8k
>> NAME         PROPERTY  VALUE  SOURCE
>> tank/tst-8k  used      10.3G  -
>> root at kadlubek:~ # zfs get used tank/tst-16k
>> NAME          PROPERTY  VALUE  SOURCE
>> tank/tst-16k  used      10.2G  -
>> root at kadlubek:~ # zfs get used tank/tst-32k
>> NAME          PROPERTY  VALUE  SOURCE
>> tank/tst-32k  used      10.1G  -
>> root at kadlubek:~ # zfs get used tank/tst-64k
>> NAME          PROPERTY  VALUE  SOURCE
>> tank/tst-64k  used      10.0G  -
>> root at kadlubek:~ # zfs get used tank/tst-128k
>> NAME           PROPERTY  VALUE  SOURCE
>> tank/tst-128k  used      10.0G  -
> 
> 
> Nope, that all looks correct. There is space reserved for metadata
> (checksum for example) when you create a zvol. Since checksums are computed
> by block, it makes sense that more metadata is required for the 8k
> volblocksize.

Also, the smaller the data blocks the more indirect blocks are needed to cover
the same size.

-- 
Andriy Gapon


More information about the freebsd-fs mailing list