+ dev@ceph.io I'm responding via the mailing list (with you on copy) to ensure other developers interested in Crimson and ceph-volume can follow this discussion. While I believe this very topic primarily concerns Crimson rather than ceph-volume, I'll continue the conversation in this thread to maintain context for all interested parties. On Fri, Oct 10, 2025 at 9:11 PM Anthony D'Atri <aad@dreamsnake.net> wrote:
Including aligning with coarse IU QLC block sizes?
The problem of guaranteeing I/Os at IU size involves multiple layers: - seastar: use the minimal (or optimal) unit for performing dma writes. - crimson: use the optimal size for performing writes if seastar intends to be more conservative, and uses the minimal write size. - ceph-volume if crimson is not able to detect the i/o granularity properly, and it exposes an interface allowing tools like ceph-volume to configure it, with, for instance, a tag in the device. ceph-volume could probably detect the device's optimal setting, and persist the i/o size in the tag. Currently, seastar uses 4K for block device's dma writes. after reviewing its implementation, i created - https://github.com/scylladb/seastar/pull/3045 : Improves DMA write alignment using block device properties - https://github.com/scylladb/seastar/pull/3046 : Enhances I/O size detection mechanisms These changes move Seastar from hardcoded 4K writes to using the device's reported optimal block size. But if we are aiming at a higher performance than what is provided by minimal_io_size, and if QLC devices expose a different size with, for example, sys/block/<device>/queue/optimal_io_size, we should use it instead. probably it's not seastar's responsibility to use this number, but crimson could take it into consideration when streaming the data to the device. If crimson cannot reliably detect the I/O granularity, we could expose a configuration interface allowing tools like ceph-volume to set this via, for instance, device's superblock. Probably as you noticed, so far, we've being discussing seastar and crimson instead of ceph-volume, the reason is that the i/o granularity is more relevant to crimson than ceph-volume, unless crimson is not able to use the reported number from the system. On Oct 10, 2025, at 12:15 AM, kefu chai <tchaikov@gmail.com> wrote: I've been focusing on adding support for Seastore's secondary devices (for tiering)
-- Regards Kefu Chai