>>> The Lee-Man <leeman.dun...@gmail.com> schrieb am 21.10.2021 um 17:55 in Nachricht <8d711f1e-d3f4-4109-87ed-a950e93298...@googlegroups.com>: > Hi Ulrich: > > I don't see how systemd is going to run parallel iscsiadm commands, at > least with the units that come with open-iscsi. Systemd actually guards > against that.
Actually my statement was not specific to iscsiadm, but general: If serveral systemd services depend on one systemd target, those services are started in parallel (unless other conditions prevent that) when that target is to be reached. > > As far as locking, I'd be glad to entertain/discuss/review patches that > make iscsiadm behave well when run in parallel. But such as change isn't on > my short list of things to work on, since I don't really see the need. I'd > rather focus on making iscsid play well in containers. > > On Wednesday, October 20, 2021 at 11:19:24 PM UTC-7 Uli wrote: > >> Hi! >> >> Another thing is: Whether you like systemd or not: It runs many processes >> automatically and concurrently. >> So it seems wise that iscasadm may be run concurrently. If there are >> issues, iscsiadm should use a MUTEX internally to avoid those IMHO >> >> Regards, >> Ulrich >> >>> Vojtech Juranek <vjur...@redhat.com> schrieb am 20.10.2021 um 08:58 in >> Nachricht <4882593.9...@localhost.localdomain>: >> > Hi, >> > I'd like to follow up with discussion about concurrent usage iscsiadm >> tool. >> > It >> > was discussed here about year ago, with suggestion not to use it >> > concurrently >> > [1]. On the other hand, comment [2] says it should be fine. Is the an >> > agreement >> > in open-iscsi community if the concurrent usage of iscsiadm is safe or >> not? >> > If >> > it's not safe, is there any bug for open-iscsi describing the issue and >> > potential problems if iscsiadm is used concurrently? >> > >> > The motivation why I'm popping up this again is that in oVirt project >> [3] we >> > >> > use a lock before calling iscsiadm to make sure it's not run in >> parallel. >> > This >> > causes us various issues (see e.g. BZ #1787192 [2]) and we'd like to get >> rid >> > >> > off this lock. >> > >> > I run several thousands tests with our typical usage of iscsiadm [4], >> > running >> > iscsiadm in parallel and haven't spot any issue so far. This suggests >> > removing >> > the lock can be safe, but of course my tests could be just a pure luck. >> So >> > before removing this lock from our code base, I'd like to know your >> thoughts >> > >> > about it. >> > >> > Thanks >> > Vojta >> > >> > [1] https://groups.google.com/g/open-iscsi/c/OHOdIm1W274/m/9l5NcPQHBAAJ >> > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1787192#c18 >> > [3] https://www.ovirt.org/ >> > [4] https://github.com/oVirt/vdsm/blob/master/tests/storage/stress/ >> > initiator.py >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "open-iscsi" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an >> > email to open-iscsi+...@googlegroups.com. >> > To view this discussion on the web visit >> > >> > https://groups.google.com/d/msgid/open-iscsi/4882593.9CP3fYhb5E%40localhost.l > >> > ocaldomain. >> >> >> >> >> > > -- > You received this message because you are subscribed to the Google Groups > "open-iscsi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to open-iscsi+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/open-iscsi/8d711f1e-d3f4-4109-87ed-a950e932 > 9895n%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/61727827020000A100044BFD%40gwsmtp.uni-regensburg.de.
