<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hello,<br>
<br>
I'll try to explain how works fcoe-utils.<br>
<br>
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.<br>
<br>
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<br>
<br>
This deb package has been tested
(reboot/start/stop/install/uninstall) under our infrastructure and
works with this following Hardware :<br>
<br>
BL465c Gen8 with HP VC FlexFabric-20/40 F8 Module (embeddeb with <span
class="ellipsis_text">QLogic QMH2572 8Gb FC HBA for HP
BladeSystem c-Class) in a HP C7000 Enclosure</span><br>
<br>
On related link :
<a class="moz-txt-link-freetext" href="https://www.kernel.org/doc/Documentation/scsi/bnx2fc.txt">https://www.kernel.org/doc/Documentation/scsi/bnx2fc.txt</a><br>
<br>
Regards,<br>
<br>
<pre class="message">--
🐧 M. Sylvain COSTARD
🎓 Université Rennes 2
Direction du Système d'Information
Pôle Infrastructure / Serveurs
🔗 <a href="http://www.univ-rennes2.fr/dsi">http://www.univ-rennes2.fr/dsi</a></pre>
<br>
<br>
<br>
Le 25/01/2017 à 22:43, Jacob Luna Lundberg a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:20170125214300.GT6309@asandir.lunixsys.com">
<pre wrap="">
Hi Felipe,
On Wed, Jan 25, 2017 at 03:00:29PM -0300, Felipe Sateler wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">It is plenty usable, just not if you are using systemd. Yes, I am aware
policy at this point requires systemd support.
</pre>
</blockquote>
<pre wrap="">
OK, sorry. The impression I had from your earlier message is that it
didn't work[1].
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
Given the description of Type=forking that does sound sensible.
</pre>
<blockquote type="cite">
<pre wrap="">debian/rules:
=> it seems weird to me that the socket is not started by default.
</pre>
</blockquote>
<pre wrap="">
Maybe something to do with the hack-y version of dealing with forking?
Thanks,
-Jacob
</pre>
</blockquote>
<br>
</body>
</html>