Hello experts:
I am working on PR support for RBD in user space, aka, give tcmu-runner
rbd handler ability to handle Persistent Reservation operations. Now RBD
handler side works fine, I can capture the CDBs, analyze it, store/ read
keys, also other supportive codes done and works fine.
But I need to pass through some session information to tcmu-runner, like
initiator name and port information. I have three proposals on this
feature, hope and eager to get some suggestions
(I like the first one, if you have quite limited time, please read
number 1).
(1)I think this idea may work, using configFS, we can create a configFS
group like tcmu/rbd(or other handler entries)/rbd_name/command_id(we
already have it in the command entry header, not require the header file
chagnes), then store some key-value pairs there, like "initiator_name"
as key(file name) and "iqn.xxxx-xxx.xxxxxx" as value(file content), when
we need to exchange session information, we can create such groups and
attributes, after processing them, we can delete/free them. Yes, this
may require an additional lock. I think it is simple, easy, not messy.
And someday if we need to send some information to kernel side other
than sense buffer, we can also use it!
(2)Add such information in the command entry header( tcmu_cmd_entry.hdr
) like command id which is already there. But just for initiator name
this may require 224 bytes at most, and we may need another bool bit to
tell user space whether there is an initiator sent out, because is would
be a waste if we pass initiator name every time even not needed. Maybe
this is not a good idea, because when we need to pass through other
information, we may make the header quite messy, I think it is nice to
keep it simple. The biggest problem is, the header file
/usr/include/linux/target_core_user.h belongs to the package
"linux-glibc-devel", this package always take half a year for updating.
This means if we changed this header file(it is a copy of kernel
header), we need to wait almost half a year for sync, or tcmu-runner can
not build. So I think this is not a workable idea.
(3)Add such information in the io_vec, this means
entry->req.iov[iov_cnt], this can work, but will make io vec quite
messy. And ugly, because such session information are not operational
data which is io_vec should contain. And we also need additional bool
bit to tell user space which kind of session information we pass through
to tcmu-runner. So I think it is also not a workable idea.
Thanks for reading my mail, thanks for your help, I tend to use the
third one(and actually working on it), I hope can get some suggestions!
Or a better idea!
Thanks for your time,
BR
Zhu Lingshan
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
