On 10/11/2013 06:59 PM, Seth Call wrote:
Without having looked at the code, the 'saveconfig' command sure looks like it's not concurrency-safe. One thing that drove me absolutely crazy about itadm/stmfadm on Illumos was that it's not concurrency-safe. Commands would fail mysteriously once you did that, and had to resort to a reboot. It's very hard to readily build a program that shares the same CLI that administrators use, if it can't be used concurrently. Basically, the administrator can't know whether when he tries to run a command, if the program is doing the command at the same time. You would have to build some lock around targetcli to protect it. And you can't know that other tools don't use targetcli periodically. On Illumos, because of these limitations, we built a web server that would only allow one request to be processed at a time, serializing all commands; but it didn't stop the adminsitrator from using the command. Also, a web administration portal that we didn't build, napp-it, also used those same commands. So all of our engineering was ultimately flawed, because we didn't address the underlying issue of command concurrency. I apologize if saveconfig is concurrency-safe, but because it appears that it saves *everything*, I'm pretty safe in making this assumption.
OK, I've been looking at this some more. So if we just establish a convention that before accessing configfs, everyone should lockf(2) on /var/run/target.lock, then we're good? If you had process A which was clearing the config and process B that was saving it, this would ensure that B didn't save a half-cleared config. That's the problem we're solving here, right?
Regards -- Andy -- 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
