os/bluestore: proper override rocksdb::WritableFile::Allocate

[ifed01]

Failing to do that makes BlueFS file frgmentation higher.

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

[aclamk]

Do now we have to do the same for:
rocksdb::Status RangeSync(off_t offset, off_t nbytes) ?

[aclamk]

Nice!

[aclamk]

@ifed01
I created https://tracker.ceph.com/issues/58966 to track this back.
Can you please update commit message?

[ifed01]

Do now we have to do the same for: rocksdb::Status RangeSync(off_t offset, off_t nbytes) ?

yep, done.

[ifed01]

@ifed01 I created https://tracker.ceph.com/issues/58966 to track this back. Can you please update commit message?

done

[baergj]

FWIW, I played with this a bit in a staging environment and didn't see any measurable differences to latency or write amp.

[ifed01]

FWIW, I played with this a bit in a staging environment and didn't see any measurable differences to latency or write amp.

First of all this is definitely not a major performance improvement... It just potentially decreases sst files fragmentation. Which should be visible through ceph-bluestore-tool's bluefs-log-dump command output. And the following considerations might apply as well:

1. Aged volumes under high load are more susceptible to cause sst fragmentation/expose negative effect.
2. The patch slows down volumes' aging/fragmentation.
3. DB on top of spinning drive is apparently the major winner

[ifed01]

FWIW, I played with this a bit in a staging environment and didn't see any measurable differences to latency or write amp.

First of all this is definitely not a major performance improvement... It just potentially decreases sst files fragmentation. Which should be visible through ceph-bluestore-tool's bluefs-log-dump command output. And the following considerations might apply as well:

1. Aged volumes under high load are more susceptible to cause sst fragmentation/expose negative effect.
2. The patch slows down volumes' aging/fragmentation.
3. DB on top of spinning drive is apparently the major winner

[baergj]

Yeah, understood - I just wanted to confirm that it had effectively zero effect on an nvme test system. I figured that HDDs would be the big winners here.

[ifed01]

jenkins test make check

[ljflores]

Rados suite review: https://tracker.ceph.com/projects/rados/wiki/MAIN#httpstrellocomclM1xjBe01744-wip-yuri-testing-2023-05-10-0917