Re: bluestore_compression_min_blob_size vs. bluestore_compression_min_blob_size_<type>

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Adam,

I've been focus on global compression, not per pool.

In case of global compression, only compression_(min/max)_blob_size_(ssd/hdd)
takes effect, compression_(min_max)_blob_size has no effect to global compression
at all. Is that correct?

If yes, it makes sense, but I'd name it compression_(min_max)_blob_size_per_pool
or something more clear.

Thanks!
Tony
________________________________________
From: Adam Kupczyk <akupczyk@xxxxxxxxxx>
Sent: August 29, 2023 01:04 AM
To: Tony Liu
Cc: dev@xxxxxxx
Subject: Re: bluestore_compression_min_blob_size vs. bluestore_compression_min_blob_size_<type>

Hi Tony,

Initially:
1) values for compression min and max blob size are taken from compression_(min/max)_blob_size_(ssd/hdd)
but if value of compression_(min_max)_blob_size is set to non-0
2) that value is used as compression blob size in bluestore
but if a pool has set compression_(min/max)_blob_size setting
3) that value is used as compression blob size

I do not understand why you think of it as inverted priority.
The most generic case ceph tries to guess the best blob size by type of media hw.
Once you know your hw you can override blob sizes using your knowledge.
And even further - you can have different expectations for blob sizes depending on type of data you have.
For a pool with large unchanging objects (RGW?) you could choose a very large blob size.
For a pool where you expect small accesses (RBD?) you probably want a smaller blob.

Best regards,
Adam Kupczyk


On Fri, 18 Aug 2023 at 19:54, Tony Liu <tonyliu0592@xxxxxxxxxxx<mailto:tonyliu0592@xxxxxxxxxxx>> wrote:
Hi Adam,

This priority order is different from common sense, where specific setting has higher
priority than generic setting. With this order, compression_min_blob_size has higher
priority, then what's the point of having _hdd or _ssd settings, which will never get applied?


Thanks!
Tony
________________________________________
From: Adam Kupczyk <akupczyk@xxxxxxxxxx<mailto:akupczyk@xxxxxxxxxx>>
Sent: August 17, 2023 11:00 PM
To: Tony Liu
Cc: dev@xxxxxxx<mailto:dev@xxxxxxx>
Subject: Re: bluestore_compression_min_blob_size vs. bluestore_compression_min_blob_size_<type>

Hi,

First priority for compression blob is per-pool setting (taken if set)
# ceph osd pool get test compression_min_blob_size
Second, if set, bluestore_compression_min_blob_size config,
Third is selected from *_hdd *_ssd depending on the main block device in the OSD being HDD or SSD.
This can be forced by setting bluestore_debug_enforce_settings to either 'hdd' or 'ssd' if your hardware improperly reports
# cat /sys/block/sda/queue/rotational
0

Blob is an organization unit in BlueStore
https://github.com/ceph/ceph/pull/51933

You can get compression for blocks smaller than 4K only if your main device has native block size smaller.
# cat /sys/block/nvme1n1/queue/physical_block_size
512
In such a case you can set bluestore_min_alloc_size (in effect only during mkfs) to some value smaller than 4K, but multiply of 512.

This path is not often tested, and you need to own unexpected side effects.

Best regards,
Adam Kupczyk




On Wed, 16 Aug 2023 at 19:46, Tony Liu <tonyliu0592@xxxxxxxxxxx<mailto:tonyliu0592@xxxxxxxxxxx><mailto:tonyliu0592@xxxxxxxxxxx<mailto:tonyliu0592@xxxxxxxxxxx>>> wrote:
Hi,

With Pacific and afterwards, which of the following two settings takes precedence?
bluestore_compression_min_blob_size    (default 0)
bluestore_compression_min_blob_size_<type>    (default 8192)

I'd assume the more specific setting takes precedence?
What's this "blob"? Is it write block?
Then, there is no compression for 4K write block?

I was not able to find it out from doc, hope someone could help to clarify.


Thanks!
Tony
_______________________________________________
Dev mailing list -- dev@xxxxxxx<mailto:dev@xxxxxxx><mailto:dev@xxxxxxx<mailto:dev@xxxxxxx>>
To unsubscribe send an email to dev-leave@xxxxxxx<mailto:dev-leave@xxxxxxx><mailto:dev-leave@xxxxxxx<mailto:dev-leave@xxxxxxx>>



_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx



[Index of Archives]     [CEPH Users]     [Ceph Devel]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux