Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 13 Aug 2022 22:41:33 -0400
From:      Dan Mahoney <freebsd@gushi.org>
To:        Doug Ambrisko <ambrisko@ambrisko.com>
Cc:        Ruslan Makhmatkhanov <rm@freebsd.org>, "ports@freebsd.org" <ports@freebsd.org>, "samflanker@gmail.com" <samflanker@gmail.com>
Subject:   Re: MegaCLI port is ports-only -- how would you deploy it?
Message-ID:  <BFBA2F65-02C0-40C6-99E5-407424D3DD0B@gushi.org>
In-Reply-To: <YvaBW6vmBggMpGek@ambrisko.com>
References:  <1615CF76-EE45-4D11-8102-EA441E845E65@gushi.org> <635211659622624@mail.yandex.ru> <YvFqwVjOhYxHTf%2By@ambrisko.com> <493ED6A6-A38F-47B1-B534-9F5CB14DB087@gushi.org> <YvF18opVZHg%2B1W%2BR@ambrisko.com> <1578B277-8FB1-4EAB-ACDB-8ACE6E999857@gushi.org> <YvaATQiz2GF8qFRT@ambrisko.com> <9EC7D5D4-0DD2-4946-9C5F-ADB2B39B73F1@gushi.org> <YvaBW6vmBggMpGek@ambrisko.com>

next in thread | previous in thread | raw e-mail | index | archive | help


> On Aug 12, 2022, at 12:35, Doug Ambrisko <ambrisko@ambrisko.com> =
wrote:
>=20
> On Fri, Aug 12, 2022 at 12:32:56PM -0400, Dan Mahoney wrote:
> |=20
> |=20
> | > On Aug 12, 2022, at 12:31, Doug Ambrisko <ambrisko@ambrisko.com> =
wrote:
> | >=20
> | > On Fri, Aug 12, 2022 at 12:21:36PM -0400, Dan Mahoney wrote:
> | > |=20
> | > | > On Aug 8, 2022, at 16:45, Doug Ambrisko =
<ambrisko@ambrisko.com> wrote:
> | > | >=20
> | > | > On Mon, Aug 08, 2022 at 04:10:10PM -0400, Dan Mahoney wrote:
> | > | > |=20
> | > | > |=20
> | > | > | > On Aug 8, 2022, at 15:57, Doug Ambrisko =
<ambrisko@ambrisko.com> wrote:
> | > | > | >=20
> | > | > | > On Thu, Aug 04, 2022 at 05:22:29PM +0300, Ruslan =
Makhmatkhanov wrote:
> | > | > | > |    03.08.2022, 02:07, "Dan Mahoney" <freebsd@gushi.org>:
> | > | > | > |      Hey there all,
> | > | > | > |      At the dayjob we have a fleet of Dell Poweredge =
servers that can use
> | > | > | > |      either mptsas or mrsas -- if you use mptsas, you =
use mptutil (in
> | > | > | > |      base) to check the state of the card.
> | > | > | > |      If you use mrsas, you need megacli, which is only =
in ports, and the
> | > | > | > |      port hasn't translated to pkg probably because of =
license
> | > | > | > |      restrictions. ( _LICENSE_RESTRICTED =3D =
delete-package
> | > | > | > |      delete-distfiles), but the license listed is just =
"megacli".
> | > | > | > |      * We want to deploy a cron job to periodically =
check the raid status
> | > | > | > |      (we're writing a wrapper, also having it check =
mfiutil, zpool, etc).
> | > | > | > |      * We do not want to install and manage a whole =
ports tree on every
> | > | > | > |      machine in our fleet, just to install a raid =
utlity.
> | > | > | > |      Option A:
> | > | > | > |      Make a local package somehow.
> | > | > | > |      The port just downloads a static binary, there's =
nothing to build
> | > | > | > |      here, but we want to do this the "right" way. Is =
there some way to
> | > | > | > |      have pkg deploy a single local package for this =
that will, for
> | > | > | > |      example, report the right package ownership, =
without moving every
> | > | > | > |      other package to our poudriere install (we're just =
using base
> | > | > | > |      packages, we keep poudriere around for testing in =
case we need to
> | > | > | > |      hot-patch something).
> | > | > | > |      For what it's worth, we use puppet for config =
management, so pushing
> | > | > | > |      out the static binary is not the worst answer, but =
it also feels
> | > | > | > |      "dirty".
> | > | > | > |      Option B:
> | > | > | > |      Figure out how to fix the license. I have no idea =
what this would
> | > | > | > |      involve.
> | > | > | > |      Option C:
> | > | > | > |      Also, apparently MegaCLI is no longer maintained =
(replaced by
> | > | > | > |      StorCLI), but there's no port for StorCLI, =
and...there are multiple
> | > | > | > |      raid-card specific versions? Jeez.
> | > | > | > |      Feels even more dirty.
> | > | > | > |      =
[1]https://support.siliconmechanics.com/portal/en/kb/articles/storcl
> | > | > | > |      i-for-freebsd-and-other-operating-systems
> | > | > | > |      Ideas welcome?
> | > | > | > |      -Dan Mahoney
> | > | > | >=20
> | > | > | > Although the path to get to StorCli goes through various =
cards the
> | > | > | > latest greatest seem to work on all earlier cards.  It =
works on
> | > | > | > HBAs and not just RAID cards.  At work I did a =
Linux/FreeBSD
> | > | > | > POC for FW management and found the FreeBSD version could =
flash the HBA
> | > | > | > and drive FW.  I've moved to StorCli from MegaCli.  I =
would suggest
> | > | > | > we drop the MegaCli port and move to StorCli.
> | > | > | >=20
> | > | > | > I have code to make mfiutil into mrsasutil and added the =
MFI ioctl
> | > | > | > handler to mrsas.  I'm not sure how much value that has.  =
I don't
> | > | > | > deal with supporting FreeBSD and RAID much anymore.  If =
interested
> | > | > | > I could send patches.
> | > | > |=20
> | > | > | This feels like it should be in base, regardless.  Just =
*something* to=20
> | > | > | query the raid status and health, even if it doesn't ring =
all the bells=20
> | > | > | of StorCLI.
> | > | > |=20
> | > | > | Right now, you can do this with the older mfi, but not the =
newer mrsas,=20
> | > | > | which performs better in some cases, which leaves an admin =
with a=20
> | > | > | dilemma: better reliability, or better manageability.
> | > | > |=20
> | > | > | I also feel like this could be added to a minor release =
(i.e. a=20
> | > | > | 12.3 --> 12.4 or a 13.0 --> 13.1), but obviously that =
decision is above me.
> | > | >=20
> | > | > This is based of -current.  I haven't tested it recently:
> | > | > 	=
https://people.freebsd.org/~ambrisko/git.mrsas_support_in_mfiutil.patch
> | > | >=20
> | > | > Please give it a try.  You will need a new kernel built and =
booted to
> | > | > provide the needed ioctl support.  It should be close to =
committable.
> | > |=20
> | > | Doug,
> | > |=20
> | > | I'm trying this out on 12.x and 13.x just for funsies, but given =
the=20
> | > | release schedule, it's unlikely that there'll be a 12.4 or a =
13.2 that=20
> | > | this would make it into.  Regardless, I've opened a bug report =
to get=20
> | > | this added *somewhere* which may cause other people to try it =
out and test.
> | >=20
> | > I'd have to put in -current first then look at MFC later on.  If =
looks
> | > good for you then I'll put it up for review.  I just don't use =
this
> | > stuff day to day anymore.
> |=20
> | Yeah, most of our dayjob work is running critical DNS =
infrastructure, so=20
> | there's not a lot of -current there, but I can get permission to =
play=20
> | with it on a spare system.
>=20
> It should apply to earlier releases, since there hasn't been a lot of
> changes in this area.  So you can try that if that is easier.  I did
> this code a long time ago probably in 10.X and have been moving it
> forward.

I've confirmed that it shows drive status and array status on my R430 =
running FreeBSD 14.0-CURRENT #0 main-n257330-88951aaaee7-dirty in mrsas =
mode.

As currently built, the kernel makefiles do not install it as mrsasutil, =
and this is a manual copy.  I think that would need to be fixed to make =
it mergeable, but I think it should happen.

I've opened this PR: =
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D265794

At this point, the ports- list is probably off-topic for this, but this =
conversation should definitely continue.

-Dan=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BFBA2F65-02C0-40C6-99E5-407424D3DD0B>