Missing rbd API components: function rbd_read_iterate2

[phlogistonjohn]

The rbd API implements function(s) below but go-ceph does not:

• rbd_read_iterate2

This issue has been filed to track implementing this missing
functionality in the appropriate package within go-ceph.
Please refer to the Ceph C API for details about the function(s)
in question.

NOTE: This issue was generated by a script.
If the content is innacurate or wording seems a bit odd
please excuse the script and blame the creator @phlogistonjohn

[tareksha]

hi, any progress on this?

[phlogistonjohn]

No, generally you can assume something has not been investigated yet when there's no assignee, other comments or PR.

However, comments like yours help us know there is interest in a feature and help get things prioritized. By the way, what's your use case for this function?

[tareksha]

@phlogistonjohn We maintain many ceph clusters in the cloud. A dedicated component continuously exports selected RBD images for external long-term storage and imports them back when needed. The lack of rbd-cli-like "export" (both volume contents and metadata) forces us to fork rbd cli processes from go code. Since we have to fork the cli anyway we ended up not using go-ceph at all.
We really want to do it the right way and stop forking cli external processes from go code.

[phlogistonjohn]

I started looking into this and it doesn't look too challenging. In many ways it's similar to our existing diff iterate support.

However, what's not clear to me is why you need this particular call versus an existing api like Read/ReadAt. I'm guessing it could be related to hole detection but it'd be nice to know for sure if that's the use case. Regardless, we'll probably add it, but I'm nosy and like to know why someone picks one interface over another. :-)

[phlogistonjohn]

I've created a preliminary implementation at #624.
At this time I can't reproduce the behavior of hole detection that the function in ceph is noted to have. I'll look into that after the holidays.

In the meantime you may just want to look into using Read and/or ReadAt calls unless you strongly need hole detection at the ceph layer.

[tareksha]

Thanks for the quick response @phlogistonjohn !

[phlogistonjohn]

https://tracker.ceph.com/issues/3619

It appears that the sparse file "hole" detection does not work properly. And it has not for a while.

I can implement it without unit tests to verify hole detection works and "just hope" that ceph rbd team fixes the issue at some point. But I'm not clear if that's valuable to our users.
@tareqhs since you have interest in the API - how important is hole detection to your use case? Since the hole detection doesn't work would Read/ReadAt calls that are already in the library sufficient for your use? Or are you interested in this api for other reasons?

[phlogistonjohn]

It's been over two weeks since I checked up on the requirement to detect "holes".
Based on the non-response I think I will abandon PR #624 since without hole detection it adds very little value on top of the existing read and write calls available in the rbd package already. In addition, I'm going to relabel the issue so that we know the reason we're not wrapping it isn't lack of time/interest but ceph issues.
This doesn't mean that the issue will never be taken up again, but I do suggest that if there's interest in the api either discuss the lack of hole detection with the rbd team in ceph or explain why this API, without hole detection, is needed over existing APIs.

Thanks!