os/bluestore: get rid off resulting lba alignment in allocators

[ifed01]

Fixes: https://tracker.ceph.com/issues/63618
Fixes: https://tracker.ceph.com/issues/62815

Signed-off-by: Igor Fedotov igor.fedotov@croit.io

Contribution Guidelines

• To sign and title your commits, please refer to Submitting Patches to Ceph.

• If you are submitting a fix for a stable branch (e.g. "pacific"), please refer to Submitting Patches to Ceph - Backports for the proper workflow.

Checklist

• Tracker (select at least one)
  • References tracker ticket
  • Very recent bug; references commit where it was introduced
  • New feature (ticket optional)
  • Doc update (no ticket needed)
  • Code cleanup (no ticket needed)
• Component impact
  • Affects Dashboard, opened tracker ticket
  • Affects Orchestrator, opened tracker ticket
  • No impact that needs to be tracked
• Documentation (select at least one)
  • Updates relevant documentation
  • No doc update is appropriate
• Tests (select at least one)
  • Includes unit test(s)
  • Includes integration test(s)
  • Includes bug reproducer
  • No tests

Show available Jenkins commands

• jenkins retest this please
• jenkins test classic perf
• jenkins test crimson perf
• jenkins test signed
• jenkins test make check
• jenkins test make check arm64
• jenkins test submodules
• jenkins test dashboard
• jenkins test dashboard cephadm
• jenkins test api
• jenkins test docs
• jenkins render docs
• jenkins test ceph-volume all
• jenkins test ceph-volume tox
• jenkins test windows

[YiteGu]

We no longer need 64k alignment, but could we still keep 4k alignment for every time alloc?

[markhpc]

We no longer need 64k alignment, but could we still keep 4k alignment for every time alloc?

I had a similar thought when we were talking about this a couple of weeks ago. I'm not sure why we want to go completely unaligned. @ifed01 any chance you could describe your thinking here? I never quite understood the rationale during our discussion.

[ifed01]

We no longer need 64k alignment, but could we still keep 4k alignment for every time alloc?

Primary allocation unit (4K by default) alignment is still preserved.

[ifed01]

We no longer need 64k alignment, but could we still keep 4k alignment for every time alloc?

I had a similar thought when we were talking about this a couple of weeks ago. I'm not sure why we want to go completely unaligned. @ifed01 any chance you could describe your thinking here? I never quite understood the rationale during our discussion.

https://tracker.ceph.com/issues/62815 should be able to provide some clue. Here is a brief overview:
When bluefs asks for 64K continuous blob the previous implementation attempted to locate such a chunk with an LBA aligned to 64K. But avl allocator tracks free chunks in buckets depending of their sizes. I.e. there is a bucket where all 64K chunks are kept. And in this bucket they're ordered by their LBAs only. Hence to find 64K aligned chunk one has to sequentially iterate through a potentially long list of chunks which are still 64K length but doesn't match the alignment requirement. Hence the performance impact. And actually there is no real need for that LBA's alignment requirement for now - hence the suggestion to get rid of it

[YiteGu]

@markhpc @aclamk Can we accelerate the review of this modification? I want to use it as soon as possible.

[ljflores]

@YiteGu it has been put in a test batch; Shaman builds were failing yesterday, but we're having better luck today. Will get it tested ASAP.

[ljflores]

jenkins test api

[ifed01]

jenkins test make check

[ifed01]

jenkis test windows

[ifed01]

jenkins test windows

[YiteGu]

@YiteGu it has been put in a test batch; Shaman builds were failing yesterday, but we're having better luck today. Will get it tested ASAP.

thx, @ljflores BTW, I already backport to 16.2.14 and build by self.
@ifed01 The fact proves that this patch is very effective.

[ljflores]

Rados approved https://tracker.ceph.com/projects/rados/wiki/MAIN#httpstrellocomcwK3QrkV21901-wip-yuri-testing-2023-12-06-1240