Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Apr 2013 12:43:52 +0530
From:      "Desai, Kashyap" <>
To:        Kevin Day <>, Scott Long <>
Cc:        "" <>
Subject:   RE: New Driver for MegaRaid 6Gb/s and 12Gb/s Card
Message-ID:  <>
In-Reply-To: <>
References:  <> <1366236517.1499.31.camel@localhost> <> <> <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

> -----Original Message-----
> From: Kevin Day []
> Sent: Friday, April 19, 2013 11:28 PM
> To: Scott Long
> Cc: Desai, Kashyap;
> Subject: Re: New Driver for MegaRaid 6Gb/s and 12Gb/s Card
> On Apr 19, 2013, at 10:59 AM, Scott Long <> wrote:
> >
> > What will the exposed device names of the arrays be under the new
> driver?  Will it still be /dev/mfid* ?  If it's not, then this is where
> the problem lies.  Many users still use device names in their /etc/fstab
> for mounting all of their filesystems at boot.  If you have two drivers
> that will compete for the same hardware and give that hardware different
> names, they will break the fstab files for those users and they upgrade
> over time.  A similar situation occurred several years ago with the
> Intel e1000 driver; it was split into two drivers, with certain hardware
> that was supported by the old hardware going to the new driver.  That
> broke the network configuration for many users and caused years of pain
> and unhappiness as users upgraded and were hit by the switch.  We don't
> want that to happen here.
> >
> > The real solution is that we need to have a single common naming
> convention for all disks (and for network interfaces), and leave the
> details of individual driver names out of the configuration part of the
> system.  That's not likely to happen any time soon.  The other solution
> is to mandate that users use volume labels for mounting their
> filesystems, but that's not likely to happen either, and even if it did,
> it present challenges for migrating existing users.  The only remaining
> solution that I can think of is to have the mfi and mrsas drivers share
> the same devclass for their disk interfaces (mfid*), but that's a hack
> that has not been fully explored in FreeBSD.  Still, I'd encourage you
> to try it and see if you can make it work.  If you have any problems,
> email me directly.
> Some Linux distributions had a flag day where upgrading beyond a certain
> point caused a one-time popup asking if you wanted to convert /etc/fstab
> to volume labels instead of device names. You could say no and proceed
> normally, but if you said Yes it rewrote fstab to use labels. I'm not
> sure where we could hook this so it happened both with freebsd-update
> and source upgrades, but it would be nice to make it painless to switch.

Thanks for sharing your early feedback. That was a main goal to discuss at =
freebsd mailing list before I submit "mrsas" driver.

Let me give more details about our design w.r.t mfi and mrsas (especially f=
or Thunderbolt Controller).
We had three different choices as described below.

#1. We could have removed Thunderbolt support from mfi and add the same sup=
port in mrsas, forcing all customers to move to mrsas.
This was really good from technical aspect, because having two Driver for s=
ingle PCI ID is not perfect solution.
But it really does not work in real world, since few customers may want to =
continue with "mfi". (at least for short to medium terms, until and unless =
they found "mrsas" is reliable for their production environment)

LSI decided to give customer an option to choose existing mfi driver for Th=
underbolt (Those who are already using mfi driver).
For those customer who wants to use first time Thunderbolt card in next Fre=
eBSD-RELEASE, can opt mrsas (because mrsas is redesigned driver and will ha=
ve better support for all upcoming PCI ID addition).

Considering above fact, We may have three typical use case.

#2 (a) . Existing customers: (Do not wants to switch to mrsas).
       For those customers, they will have choice to continue "mfi". (As of=
 now this settings are tunable through device.hints and it is a onetime eff=
       We can find the best suitable default behavior.=20

Is there any way to communicate this behavior through Release note to the c=
ustomer with FreeBSD-Next Release ?
Anyways this behavior will be well documented in "man page of mrsas".

#2 (b) Existing customers: (Wants to switch to mrsas).
This is a typical worst case. For this case, user may required few manual c=
hanges in /etc/fstab.

#2 (c) New customers: ( Using Thunderbolt first time on FreeBSD)
    For those customers, they will never see "mfi" conflict with "mrsas" dr=
iver for Thunderbolt card and for them it will be a painless installation p=

Same as above #2, except default choice will be "mfi"

With this choice we would not have any technical issue, but It would not ex=
pose our new driver "mrsas" to the end user and there is a high possibility=
 that  "mrsas" would have never been opted for Thunderbolt card, even if it=
 is available to the upstream kernel.
(LSI recommends "mrsas" driver, since this driver will have longer maintena=
nce cycle and support compare to mfi.). Because of that reason, we have dec=
ided to go with #2.

<mrsas> driver will attach device to the CAM layer, unlike mfi driver which=
 directly talks to block layer. That was a one of the main reason to re-des=
ign mrsas to use CAM layer. <mrsas> driver will expose drives as "/dev/daX"=

In summary, I agree that device name /dev/mfidX and /dev/daX will conflict,=
 but that was treated as slight disadvantage (for very specific use case) o=
ver other benefits we will offer to the end user with this new driver submi=

As mentioned by Scott if we can keep same devclass for "mrsas" and "mfi", I=
 am ok to explore those area, but it does not looks to be possible because =
our important goal in <mrsas> was to give all control to the CAM layer inst=
ead of keeping logic, which belongs to CAM layer into Low level driver.

Please let me know your thoughts.!

Thanks, Kashyap

Want to link to this message? Use this URL: <>