Hi Andy,
On 02/27/2014 08:15 PM, Andy Grover wrote:
Good to see your email. Wow, a quantum leap!
Thanks!
Some things that might also be addressed include:
- There's a possibility that configuration operations by different
users of rtslib (maybe even the same user and app, but in a different
window) might be operating on configfs at the same time, and this
could cause big trouble. Establishing a convention for a fcntl-based
lock that accessors of configfs acquire might be enough to resolve
this, or maybe the commit/rollback feature might help?
Yes. I know you are concerned about this (I saw your session patches)
and I have been thinking about how to handle this best. I have a range
of solutions in mind, but would like to discuss that on the ML to pick
the more appropriate. First of all, I plan to make the candidate
configuration persistent accross sessions. Then provide 3 options for
config mode:
1) shared - everyone edits the same config. This is ok, as every
operation is atomic: all load/set/merge/etc. ops are staged first,
checked in the stage and _then_ pushwed to the candidate config. Also,
we always consider the diff of the current config against the actual
running system just before commit, so the window to get out-of-sync is
small. If a diff still exists after commit, one would just have to redo
the commit. Which in fact could be automated I guess.
2) locked. You lock the access to the global candidate, no-one else can
enter config mode or do changes.
3) private. You enter config mode using your own private candidate.
Note that "info" gives you a full history of the operations that
affected the current candidate config, which you can undo if you want.
Of course, this is for the cli itself, and the configuration API. As for
accessing the configfs layer, either directly or through legacy rtslib
objects, there would always be a way of bypassing any mechanism in
place, so I would prefer to have sane synchronisation in the upper levels.
At the API level though, having a lock might be the most pragmatic way
to handle the access to rtlib lower-layers.
- better support for configuring ALUA? I don't think this made it into
rtslib.
Yes, this is on my todo list, as well as NPIV support, and access to PR
and sessions information.
But overall, yeah, the direction you've started to lay out could be a
big step in improving the accessibility of LIO's capabilities.
That's encouraging, thanks.
Looking forward to see where it goes, and possible community
development opportunities.
Me too, and I sincerely hope that I'll get some help to make that a
great configuration and admin environment :-)
Regards,
--
Jerome
--
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
