[OpenIndiana-discuss] ashift 13?

[Jim Klimov]

7 апреля 2015 г. 20:25:45 CEST, Jason Matthews <jason at broken.net> пишет:
>
>
>On 4/7/2015 11:07 AM, Jim Klimov wrote:
>>
>> As for inflation - whenever you have smaller zfs allocations, such as
>those "tails" from blocks sized not power of 2 thanks to compression,
>they become a complete minimal "recordsize" block such as 4k or 8k as
>native to your drives, with trailing zero-padding. Some metadata blocks
>may also fall into this category, though for larger files these are
>clustered at 16kb(?) chunks. You also have less uberblocks in the
>fixed-size ring buffer of zpool labels.
>
>I am not sure tails justifies the inflation. I can accept some
>increased 
>utilization from tails but this is totally out of line.
>
>Here is a 512b system of a database master.
>root at shard035a:/home/postgres/data/base/16414# du -hs .
>  203G   .
>root at shard035a:/home/postgres/data/base/16414# ls -l |wc -l
>     4109
>
>203GB and 4109 files.
>
>Here is the slave that I built from the master yesterday. They should
>be 
>nearly identical.
>
>root at shard035b:/home/postgres/data/base/16414# du -hs .
>  474G   .
>root at shard035b:/home/postgres/data/base/16414# ls -l |wc -l
>     4081
>
>My feeling is there are not enough tails in 4100 files to consume 271GB
>
>of storage. I dont understand what is going on just yet.
>
>j.
>
>
>
>
>> On the upside, if your ssd does compression, these zeroes will in
>effect likely count toward wear-leveling reserves ;) With hdds this is
>more of a lost space as compared to 512-byte sectored disks. However
>this just become similar to usage on other systems (ext3, ntfs)
>typically with 4k clusters anyway. So we're told to not worry and love
>the a-bomb ;)
>>
>
>
>
>_______________________________________________
>openindiana-discuss mailing list
>openindiana-discuss at openindiana.org
>http://openindiana.org/mailman/listinfo/openindiana-discuss

What layout do you have? The inflation losses are much more noticeable on raidzN than on mirrors for example (e.g. for each miniature file, tail or metadata block that used 512b*3 on a raidz2, you now use 8k*3 for example). There is also padding overhead on raidzN for incomplete-stripe files or tails, to ensure that whenever you delete something, you can stick a trivial block of at least N+1 sectors in the newly made hole.

Jim
--
Typos courtesy of K-9 Mail on my Samsung Android