Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

usr.sbin/bhyve: Add the block_rbd driver for Rados access #426

Closed
wants to merge 2 commits into from

Conversation

wjwithagen
Copy link

usr.sbin/bhyve: Add the block_rbd driver for Rados access

@wjwithagen wjwithagen changed the title Wjw wip bhyve blockrbd usr.sbin/bhyve: Add the block_rbd driver for Rados access Mar 8, 2020
Copy link
Contributor

@trociny trociny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the rbd driver does not need threads. The reason why they were needed for local driver is because it operated with sych read/write/etc functions. In the rbd case we can fully utilize aio functions and just had a queue for requests. But this can be improved later. As a POC I think the rbd driver is in a good shape.

At this stage we would need to concentrate on the first part, i.e. generalizing bhyve block_if to be able to hook third party backends. And for this we need to provide the API -- a header in /usr/include which could be used by drivers outside the base, and a way to dynamically load and register third party drivers. This seems to be missing so far.

Probably it is better to discuss in [1] though.

[1] https://reviews.freebsd.org/D23010

usr.sbin/bhyve/block_if.c Outdated Show resolved Hide resolved
usr.sbin/bhyve/block_if.c Show resolved Hide resolved
usr.sbin/bhyve/block_if.c Outdated Show resolved Hide resolved
usr.sbin/bhyve/block_if.h Outdated Show resolved Hide resolved
usr.sbin/bhyve/block_local.c Show resolved Hide resolved
usr.sbin/bhyve/block_if.h Outdated Show resolved Hide resolved

/* Room for backend-specific data. */
void *bb_opaque;
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we are going to have backends outside of the base code, I think we should have a header file with this structure defined somewhere in /usr/include.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that that is going to be a good fix for not having to include everything and the kitchensick in the port.
something like /usr/include/bhyve/block_if.h ??

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes

usr.sbin/bhyve/block_if.h Outdated Show resolved Hide resolved
@asomers
Copy link
Member

asomers commented Mar 15, 2020

I think the rbd driver does not need threads. The reason why they were needed for local driver is because it operated with sych read/write/etc functions. In the rbd case we can fully utilize aio functions and just had a queue for requests. But this can be improved later. As a POC I think the rbd driver is in a good shape.

I'm a little confused. Where does AIO come in? librados isn't actually providing a block device, so I assume you aren't talking about using POSIX AIO. Are you talking about a different Ceph AIO API?

usr.sbin/bhyve/block_local.c Outdated Show resolved Hide resolved
usr.sbin/bhyve/block_rbd.c Show resolved Hide resolved
usr.sbin/bhyve/block_rbd.c Outdated Show resolved Hide resolved
usr.sbin/bhyve/block_rbd.c Show resolved Hide resolved
Signed-off-by: Willem Jan Withagen <wjw@digiware.nl>
Signed-off-by: Willem Jan Withagen <wjw@digiware.nl>
@bsdimp
Copy link
Member

bsdimp commented Jun 11, 2021

This seems stalled... what's the latest status? It's also conflicting with block_if.c, so at the very least needs a rebase.

@wjwithagen
Copy link
Author

wjwithagen commented Jun 11, 2021 via email

@bsdimp
Copy link
Member

bsdimp commented Feb 4, 2023

It's been over a year, with no rebase. Closing. Please update and reopen if you find time.

@bsdimp bsdimp closed this Feb 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants