zfs discuss - Oct 2011 - Fwd: Re: zvol space consumption vs ashift, metadata packing

Hello, Daniel,

Apparently your data is represented by rather small files (thus
many small data blocks), so proportion of metadata is relatively
high, and your<4k blocks are now using at least 4k disk space.
For data with small blocks (a 4k volume on an ashift=12 pool)
I saw metadata use up most of my drive - becoming equal to
data size.

Just for the sake of completeness, I brought up a similar problem
and a non-intrusive (compatibility-wise) solution in this bug:
https://www.illumos.org/issues/1044

Main idea was to let ZFS users specify a minumum data block
size and alignment, while formal ashift=9 remains in place and
metadata blocks remain 512b. This fix would be a code-only
change without on-disk-format changes. There could be some
further cleverness when working with (updating) metadata,
so that hardware 4k blocks would need to be rewritten as
rarely and as fully as possible - to reduce wear and increase
efficiency - but the main idea is hopefully simple.


//Jim

On Wed, Oct 05, 2011 at 08:19:20AM +0400, Jim Klimov
wrote:
>
> Hello, Daniel,
>
> Apparently your data is represented by rather small files (thus
> many small data blocks)
It''s a zvol, default 8k block size, so yes.
> , so proportion of metadata is relatively
> high, and your<4k blocks are now using at least 4k disk space.
> For data with small blocks (a 4k volume on an ashift=12 pool)
> I saw metadata use up most of my drive - becoming equal to
> data size.
That''s pretty much my assumption, yes.
> Just for the sake of completeness, I brought up a similar problem
> and a non-intrusive (compatibility-wise) solution in this bug:
> https://www.illumos.org/issues/1044
>
> Main idea was to let ZFS users specify a minumum data block
> size and alignment, while formal ashift=9 remains in place and
> metadata blocks remain 512b. This fix would be a code-only
> change without on-disk-format changes. 
Well, other than needing to re-make a pool already created with
ashift=12..   By the time I do that, I might as well remake it onto
5k3000''s instead.. :)  
> There could be some
> further cleverness when working with (updating) metadata,
> so that hardware 4k blocks would need to be rewritten as
> rarely and as fully as possible - to reduce wear and increase
> efficiency - but the main idea is hopefully simple.
If only the implementation were too..

--
Dan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20111008/07f53b52/attachment-0001.bin>