On 01/03/2017 03:47 PM, Christian Seiler wrote: > On 01/03/2017 10:51 PM, Andrew Patterson wrote: >> On 01/03/2017 01:27 PM, Christian Seiler wrote: >>> On 01/03/2017 09:10 PM, Andrew Patterson wrote: >>>>> How does the rest of the boot process proceed then? What happens >>>>> when iscsiuio is to be started regularly at boot from the systemd >>>>> service / init script? >>>>> Is the iscsiuio from the initramfs required >>>>> to be running at all times during the iSCSI session or can it be >>>>> restarted, as long as the time during which that happens is brief >>>>> enough? Is it required to be kept around during shutdown if it's >>>>> on iSCSI? >>>> >>>> I don't believe it needs to be running to support traffic, just when >>>> doing logins. I will test to confirm. >>> >>> That would be ideal. :) >> >> I tried running a load with a data integrity check while starting and >> stopping iscsiuio numerous times. I did not see any issues either >> with performance or data integrity. > > Did you try stopping iscsiuio for longer periods of time? For > example more than 20 minutes? I would like to know what happens > if you hit ARP timeouts.
I ran it overnight (13 hours) with no issues. > >>> As far as I can tell from skimming the source iscsiuio is also >>> responsible for doing ARP and responding to ICMP - but even >>> then it wouldn't be a problem for restarting in that case, as >>> long as the MAC address of the target (or a router on the way >>> to the target) doesn't change during restart. >>> >> >> It this likely to be an issue in the one or two seconds between >> transitioning between the initramfs and sysvinit/systemd? > > It's only a couple of seconds if there's no fsck running for > another partition. Then it could easily be minutes or even > longer, depending on the partition size, the number of files > and the filesystem in question. > Granted. >>>>> Does it follow systemd's process name convention to make >>>>> sure systemd doesn't kill it during shutdown? >> >> I don't see any special handling of iscsiuio in systemd shutdown. > > I meant this: > > https://www.freedesktop.org/wiki/Software/systemd/RootStorageDaemons/ > (The @-stuff is only relevant if the binary is _not_ started > via a systemd service.) This only applies for systemd though. It won't help us for sysv-init (assuming we need to care). > > OTOH, since iscsiuio is apparently not required to be running > while data is transferred, killing it at shutdown deosn't > seem to be that big of a deal. It seems so. > >> It looks like we can use start-stop-daemon in local-top and >> local-bottom to gracefully start and stop the daemon. > > Yes, that appears to be the case. > >>>>> Before I add the aforementioned steps 1 & 2 I'd like to be sure that >>>>> this actually works properly beyond the initramfs. So any >>>>> information related to that would be appreciated. >>>> >> >> Is my current testing enough or do we need to do more? If the later, >> what sort of test would you like me to run? > > See my request above: if after 20 minutes of iscsiuio being > offline everything is still fine, I'd be fine with it. If it's > less, it depends on how much less. It looks like we are good. At least in the normal case. > > That said: your initial tests are sufficient for me to upload > a version of open-iscsi that includes support for this to > the 'experimental' suite, so I'll do that either tomorrow or > on Thursday, depending on when I'll find time for that. If you > could then test this (and write down how you set this up so > we can add it to README.Debian), and give me feedback on the > "iscsiuio is offline for longer" test, then I'd be fine with > uploading this to unstable so it makes it into Stretch. > I would be happy to test it. > Other than #850057: does iscsistart need additional changes to > work with iscsiuio? One would probably need to pass > -P iface.transport_name=bnx2i -P iface.net_ifacename=eth0 > -P iface.hwaddress=aa:bb:cc:dd:ee:ff or similar, right? > I have been using iscsstart -b with iSCSI IBFT to bring up the interface which seems to do all the required magic (at least for the iscsi_auto case). If not using iscsi_auto, the local_top script wants iSCSI login parameters on the kernel command-line. Don't forget to define OFFLOAD_BOOT_SUPPORTED, ala: diff --git a/debian/rules b/debian/rules index 906132a..562ef8d 100755 --- a/debian/rules +++ b/debian/rules @@ -3,7 +3,7 @@ #export DH_VERBOSE=1 export DEB_BUILD_MAINT_OPTIONS = hardening=+all -export DEB_CFLAGS_MAINT_APPEND = -Wall +export DEB_CFLAGS_MAINT_APPEND = -Wall -DOFFLOAD_BOOT_SUPPORTED DPKG_EXPORT_BUILDFLAGS = 1 include /usr/share/dpkg/default.mk -- Andrew Patterson Hewlett-Packard Enterprise
