Update example in rs-configuration.md

[jcjveraa]

summary:
Align example with best practices - use "aio:///dev..." instead of "/dev/..."

Background:
In preparation of experimenting with OpenEBS on a home cluster I'm reading the docs. It seems to me that the 'best practice' in the table at the end of https://openebs.io/docs/user-guides/replicated-storage-user-guide/replicated-pv-mayastor/rs-configuration#create-diskpools does not align with the subsequent example config. The best practice apparently is to prepend the device by aio:///, but in the example this is not done.
I don't know why the aio:/// or uring:/// is better so perhaps someone more knowledgable (e.g. the reviewer of this PR? :-) could add that to the docs.

If I understand the docs correctly, the example should be updated as I have done here. If this is wrong, the docs are unclear on this point and need some further clarification in my opinion.

Disk(non PCI) with disk-by-guid reference (Best Practice) Device File aio:///dev/disk/by-id/ OR uring:///dev/disk/by-id/

[jcjveraa]

No clue why line 521 shows a diff - nothing changed here. I edited this online with the GH editor, perhaps it changed some whitespace?

[tiagolobocastro]

I am also not sure

[balaharish7]

This is not an issue. It doesn't affect the output.

[tiagolobocastro]

Btw the best practice is not in relation to the aio, but specifically for using a /dev/disk/by-id/xxxxx rather than /dev/sdX or /dev/nvmeX
That being said, I think it's probably good to use a uri throughout, so lgtm

[tiagolobocastro]

I am also not sure

[jcjveraa]

👍
I will try to get this commit signed properly tomorrow such that the pipeline is happy, again something that GH online editor apparently doesn’t automatically do.

[jcjveraa]

A separate “issue” is in that case that it’s not really clear if there is a preference for a aio (which I take from your answer to be the default?) or uring. Reading up on it it’s clear that there is a difference, but it’s not immediately apparent which is “best” for OpenEBS.

If it’s a topic that may have very different answers depending on specific configuration, that may also be useful to say explicitly (essentially instructing users to run some benchmarks and see what works best for them on their hardware for their workload). Ideally a sensible default would be suggested in the docs.

In the end I expect most people will start by copying the example (the bit that I edited), so that should preferably be the “sane default”.

[jcjveraa]

👍 I will try to get this commit signed properly tomorrow such that the pipeline is happy, again something that GH online editor apparently doesn’t automatically do.

That took a bit longer, family fell ill and then I forgot for a while to be honest... Signed off now tho!

[tiagolobocastro]

A separate “issue” is in that case that it’s not really clear if there is a preference for a aio (which I take from your answer to be the default?) or uring. Reading up on it it’s clear that there is a difference, but it’s not immediately apparent which is “best” for OpenEBS.

If it’s a topic that may have very different answers depending on specific configuration, that may also be useful to say explicitly (essentially instructing users to run some benchmarks and see what works best for them on their hardware for their workload). Ideally a sensible default would be suggested in the docs.

In the end I expect most people will start by copying the example (the bit that I edited), so that should preferably be the “sane default”.

Not sure if there's a best, they are definitely different implementations and uring can yield better performance.
Perhaps we should do some IO tests with various parameters and the different modes (aio/uring/pcie).

👍 I will try to get this commit signed properly tomorrow such that the pipeline is happy, again something that GH online editor apparently doesn’t automatically do.

That took a bit longer, family fell ill and then I forgot for a while to be honest... Signed off now tho!

No worries at all, thank you for updating this and hope all is well with the family!

[tiagolobocastro]

Would you be able to update the main version of the documentation as well btw?

[jcjveraa]

Hi there Tiago, probably happy to help but not entirely clear what you're asking wrt "the main version"?

[tiagolobocastro]

Hey, sorry I should have explained. This repo is structured like this:

The main version of the documents, which is the one which will be come the next release, is on a slightly different location:
docs/main
vs
docs/*versioned_docs*/version-4.1.x

Making the changes on the main, ensures that 4.2 will have benefit from these changes.

[jcjveraa]

Clear now, thanks, and done

[tiagolobocastro]

Thanks @jcjveraa !