New Driver for MegaRaid 6Gb/s and 12Gb/s Card

[Desai, Kashyap]

> -----Original Message-----
> From: Kevin Day [mailto:kevin at your.org]
> Sent: Friday, April 19, 2013 11:28 PM
> To: Scott Long
> Cc: Desai, Kashyap; freebsd-scsi at freebsd.org
> Subject: Re: New Driver for MegaRaid 6Gb/s and 12Gb/s Card
> 
> 
> On Apr 19, 2013, at 10:59 AM, Scott Long <scott4long at yahoo.com> 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 for Thunderbolt Controller).
We had three different choices as described below.

#1. We could have removed Thunderbolt support from mfi and add the same support in mrsas, forcing all customers to move to mrsas.
This was really good from technical aspect, because having two Driver for single 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)

#2    AS A DEFAULT CHOICE "MRSAS" DRIVER WILL DETECT THUNDERBOLT CONTROLLER.
LSI decided to give customer an option to choose existing mfi driver for Thunderbolt (Those who are already using mfi driver).
For those customer who wants to use first time Thunderbolt card in next FreeBSD-RELEASE, can opt mrsas (because mrsas is redesigned driver and will have 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 effort)
       We can find the best suitable default behavior. 

Is there any way to communicate this behavior through Release note to the customer 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 changes in /etc/fstab.

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


#3.  AS A DEFAULT CHOICE <MFI> DRIVER WILL DETECT THUNDERBOLT CONTROLLER.
Same as above #2, except default choice will be "mfi"

With this choice we would not have any technical issue, but It would not expose 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 maintenance cycle and support compare to mfi.). Because of that reason, we have decided 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-design 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) over other benefits we will offer to the end user with this new driver submission.

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 instead of keeping logic, which belongs to CAM layer into Low level driver.

Please let me know your thoughts.!

Thanks, Kashyap