On Sat, Aug 27, 2022 at 06:40:29PM +0100, Richard W.M. Jones wrote:
Just clone the above branch, but can't build because of missing
ocamlbuild & ocamlcc.
But I will review the implementation from ublk viewpoint next week.
I resolved the data corruption problem once I realised that
->handle_event must only retire commands which are on the same queue
(obvious in hindsight). I ran a parallel job overnight where I did
various heavyweight operations repeatedly -- a bunch of git stuff,
large copies, a big compile etc -- on an nbdublk filesystem. It
handled everything perfectly.
It isn't strange since ublk-loop does survive xfstests before.
Before this can go upstream:
- Does libubdsrv now have a stable API, or could it change?
It is hard to answer this question now, given ublk driver is just
merged to v6.0-rc1, from then on, I started to focus on ublksrv
userspace.
But can you share what status nbdublk is now? Is it enough as one
basic nbd product?
IMO, it is pretty easy to make one toy, but very hard to build one
product, I really appreciate that you can provide some feedback
on libublksrv from viewpoint of nbdublk as product, such as,
current APIs are enough to build basic product of nbd? Are these
APIs enough to build stable enough nbd product? Are they fine to
reach expected performance?
IMO, this feedback is very helpful for evaluating if current APIs are
stable enough.
- We need to enable the device in the Fedora kernel.
OK, what is the Fedora release you plan to enable nbdublk?
- We need libubdsrv + ublk tool in Fedora.
I guess libublksrv is enough, why do you need ublk too for nbdublk?
- Possible we need to add tests into the libnbd tree. I couldn't
think of a good way to test this that doesn't require root and
potentially do some horrible stuff to the testing machine.
So far, root is still required, but in future we hope root privilege
becomes not needed.
Thanks,
Ming