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@shard035a:/home/postgres/data/base/16414# du -hs .
203G .
root@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@shard035b:/home/postgres/data/base/16414# du -hs .
474G .
root@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
[email protected]
http://openindiana.org/mailman/listinfo/openindiana-discuss
