From owner-freebsd-scsi@FreeBSD.ORG Mon Apr 22 07:14:07 2013 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 418D130A for ; Mon, 22 Apr 2013 07:14:07 +0000 (UTC) (envelope-from Kashyap.Desai@lsi.com) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by mx1.freebsd.org (Postfix) with ESMTP id 097F214BE for ; Mon, 22 Apr 2013 07:14:06 +0000 (UTC) Received: from mail126-co1-R.bigfish.com (10.243.78.229) by CO1EHSOBE029.bigfish.com (10.243.66.94) with Microsoft SMTP Server id 14.1.225.23; Mon, 22 Apr 2013 07:14:00 +0000 Received: from mail126-co1 (localhost [127.0.0.1]) by mail126-co1-R.bigfish.com (Postfix) with ESMTP id 9A99CB4008F; Mon, 22 Apr 2013 07:14:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:192.19.193.42; KIP:(null); UIP:(null); IPV:NLI; H:paledge01.lsi.com; RD:paledge01.lsi.com; EFVD:NLI X-SpamScore: -6 X-BigFish: VPS-6(zz98dI9371I148cI542I1432I4015Izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz8275bh8275dhz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah1155h) Received-SPF: pass (mail126-co1: domain of lsi.com designates 192.19.193.42 as permitted sender) client-ip=192.19.193.42; envelope-from=Kashyap.Desai@lsi.com; helo=paledge01.lsi.com ; ge01.lsi.com ; Received: from mail126-co1 (localhost.localdomain [127.0.0.1]) by mail126-co1 (MessageSwitch) id 1366614838325855_14867; Mon, 22 Apr 2013 07:13:58 +0000 (UTC) Received: from CO1EHSMHS003.bigfish.com (unknown [10.243.78.230]) by mail126-co1.bigfish.com (Postfix) with ESMTP id 4D676980047; Mon, 22 Apr 2013 07:13:58 +0000 (UTC) Received: from paledge01.lsi.com (192.19.193.42) by CO1EHSMHS003.bigfish.com (10.243.66.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 22 Apr 2013 07:13:58 +0000 Received: from PALCAS01.lsi.com (128.94.213.117) by PALEDGE01.lsi.com (192.19.193.42) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 22 Apr 2013 03:14:19 -0400 Received: from PALEXCH11.lsi.com (128.94.223.42) by PALCAS01.lsi.com (128.94.213.117) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 22 Apr 2013 03:13:57 -0400 Received: from inbexch02.lsi.com (135.36.98.40) by PALEXCH11.lsi.com (128.94.223.42) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 22 Apr 2013 03:13:56 -0400 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch02.lsi.com ([135.36.98.40]) with mapi; Mon, 22 Apr 2013 12:43:53 +0530 From: "Desai, Kashyap" To: Kevin Day , Scott Long Date: Mon, 22 Apr 2013 12:43:52 +0530 Subject: RE: New Driver for MegaRaid 6Gb/s and 12Gb/s Card Thread-Topic: New Driver for MegaRaid 6Gb/s and 12Gb/s Card Thread-Index: Ac49J3VH72FxgNncTG2733epxozH7QCAGSww Message-ID: References: <1366236517.1499.31.camel@localhost> <516FF87E.8030702@freebsd.org> <37C12059-AF0B-47C1-AD8E-1D3B4663CD3D@your.org> In-Reply-To: <37C12059-AF0B-47C1-AD8E-1D3B4663CD3D@your.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: lsi.com Cc: "freebsd-scsi@freebsd.org" X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 07:14:07 -0000 > -----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 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 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. 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. 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 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