Date: Mon, 22 Apr 2013 12:43:52 +0530 From: "Desai, Kashyap" <Kashyap.Desai@lsi.com> To: Kevin Day <kevin@your.org>, Scott Long <scott4long@yahoo.com> Cc: "freebsd-scsi@freebsd.org" <freebsd-scsi@freebsd.org> Subject: RE: New Driver for MegaRaid 6Gb/s and 12Gb/s Card Message-ID: <B2FD678A64EAAD45B089B123FDFC3ED760761F50ED@inbmail01.lsi.com> In-Reply-To: <37C12059-AF0B-47C1-AD8E-1D3B4663CD3D@your.org> References: <B2FD678A64EAAD45B089B123FDFC3ED75E70AC49E1@inbmail01.lsi.com> <1366236517.1499.31.camel@localhost> <B2FD678A64EAAD45B089B123FDFC3ED760761F4E25@inbmail01.lsi.com> <516FF87E.8030702@freebsd.org> <B2FD678A64EAAD45B089B123FDFC3ED760761F4FB0@inbmail01.lsi.com> <B5195BC9-0E44-4D69-AC25-EE2EC4035B4D@yahoo.com> <37C12059-AF0B-47C1-AD8E-1D3B4663CD3D@your.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message-----
> From: Kevin Day [mailto:kevin@your.org]
> Sent: Friday, April 19, 2013 11:28 PM
> To: Scott Long
> Cc: Desai, Kashyap; freebsd-scsi@freebsd.org
> Subject: Re: New Driver for MegaRaid 6Gb/s and 12Gb/s Card
>=20
>=20
> On Apr 19, 2013, at 10:59 AM, Scott Long <scott4long@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.
>=20
> 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.
>=20
>=20
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)
#2 AS A DEFAULT CHOICE "MRSAS" DRIVER WILL DETECT THUNDERBOLT CONTROLLER=
.
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=
ort)
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=
rocess.
#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 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=
ssion.
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: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B2FD678A64EAAD45B089B123FDFC3ED760761F50ED>