Hello, I'll try to explain how works fcoe-utils.
Fcoemon is an utility that checks for incoming devices the ability to handle fcoe. If an interface (configured in /etc/network/intefarces *AND* in /etc/fcoe/) comes up with this ability then the fcoemon will create fc_host block devices.
The original package had no systemd ability and the sysVinit system was buggy. Has Stretch tends to be systemd alike we configured it to handle it
This deb package has been tested (reboot/start/stop/install/uninstall) under our infrastructure and works with this following Hardware :
BL465c Gen8 with HP VC FlexFabric-20/40 F8 Module (embeddeb with QLogic QMH2572 8Gb FC HBA for HP BladeSystem c-Class) in a HP C7000 Enclosure
On related link : https://www.kernel.org/doc/Documentation/scsi/bnx2fc.txt Regards, -- 🐧 M. Sylvain COSTARD 🎓 Université Rennes 2 Direction du Système d'Information Pôle Infrastructure / Serveurs 🔗http://www.univ-rennes2.fr/dsi Le 25/01/2017 à 22:43, Jacob Luna Lundberg a écrit :
Hi Felipe, On Wed, Jan 25, 2017 at 03:00:29PM -0300, Felipe Sateler wrote:It is plenty usable, just not if you are using systemd. Yes, I am aware policy at this point requires systemd support.OK, sorry. The impression I had from your earlier message is that it didn't work[1].Ahh, I see. No, the package provides the utilities necessary to mount FCoE volumes, it just does not work when you try to mount them automatically at boot time. I would be curious how systemd accomplishes the necessary ordering if that is working with the systemd units. If so, when I have some time I will have to try and understand what systemd is doing. As far as I can tell this problem is not well solved, at least in sysvinit. NFS has a special arrangement. FCoE and iSCSI can't work as far as I can tell because the network must come up in order to discover volumes, but aside from NFS, volumes are mounted before the network is brought up. If Debian has a provision to mark f.e. an ext4 volume as a network volume in /etc/fstab, I do not know about it. Additionally, in sysvinit the network is stopped before unmounting volumes, so when the system attempts to unmount the FCoE volumes, the network is already down and the system waits forever for the volumes to unmount. Both of these problems can be worked around with kludgy init hacks that are not really a high enough quality to ship in Debian. Resolving these problems the right way is what I was referring to when I said the init scripts need work.0030-fcoe.service-Add-foreground-to-prevent-fcoemon-to-be.patch => Seems to me it is better to change the unit to Type=forking instead? This way, systemd would know when the monitor is ready.Given the description of Type=forking that does sound sensible.debian/rules: => it seems weird to me that the socket is not started by default.Maybe something to do with the hack-y version of dealing with forking? Thanks, -Jacob
smime.p7s
Description: Signature cryptographique S/MIME
