[OpenIndiana-discuss] ashift 13?

[Schweiss, Chip]

While the SSD will address 512b sectors, it doesn't work at all like
platters.   Like ZFS,  SSDs too will group writes together to make up 8k
sectors, do copy on write and garbage collect later.

I did a bunch of iozone testing about a year ago and found very little
benefit from using larger sector sizes on the SSD.   By far the best thing
for them was to slice them in to a partitions and use 70-90% of the
available capacity.   This gives a bigger chunk of sectors to use for
garbage collection, greatly improving sustained write performance.

This varies a lot depending on the SSD.   I did my testing on Samsung 840
Pro SSDs and Intel S3700.   The 840 Pro benefited a lot from smaller
allocations where the S3700 which already has a large over-provisioning
didn't make much difference.

BTW, the latest firmware on Intel S3500, changed to reporting 4K sectors
and 512b emulated.   They don't have near the over-provision as the more
expensive S3700, so 4K probably helps them if their entire usable partition
is used.  I use the S3500 for my rpool on most of my ZFS systems.

-Chip

On Tue, Apr 7, 2015 at 1:25 PM, Jason Matthews <jason at broken.net> wrote:

>
>
> 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
>