From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 07:52:02 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AFC9106566B for ; Thu, 21 Apr 2011 07:52:02 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 864D78FC1B for ; Thu, 21 Apr 2011 07:52:01 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 7CA2C25D37C7 for ; Thu, 21 Apr 2011 07:52:00 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id BD4A2159D681 for ; Thu, 21 Apr 2011 07:51:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id szuXukLK5dEr for ; Thu, 21 Apr 2011 07:51:57 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 6F95B159D680 for ; Thu, 21 Apr 2011 07:51:57 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1084) From: "Bjoern A. Zeeb" In-Reply-To: Date: Thu, 21 Apr 2011 07:51:56 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DAEAE1B.70207@FreeBSD.org> <20110420203754.GM85668@acme.spoerlein.net> <4DAF46F8.9040004@FreeBSD.org> To: FreeBSD-Current X-Mailer: Apple Mail (2.1084) Subject: Re: Switch from legacy ata(4) to CAM-based ATA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 07:52:02 -0000 On Apr 20, 2011, at 10:18 PM, Scott Long wrote: > On Apr 20, 2011, at 2:50 PM, Alexander Motin wrote: >> Ulrich Sp=F6rlein wrote: >>> Can we then please get the "ad" device prefix back? I seem to = remember >>> that when they were introduced they were thought to be a temporary = thing >>> ... >>>=20 >>> Unless both stacks can run in parallel, I don't see a problem with >>> having them both show up as /dev/ad0, etc. People with problems must >>> send in a complete dmesg anyway, so it should be clear what stack = they >>> are running. The POLA violation for people upgrading from 8.x to 9.0 >>> however is pretty big ... and unnecessary. >>=20 >> Stacks do can run in parallel, and it really happens when people = loading >> ahci(4) driver for SATA disks without using `options ATA_CAM` of = ata(4) >> for PATA. As result, SATA will use new stack and PATA - old one. >>=20 >> What's about POLA violation, it is inevitable, because present kernel >> uses ata(4) with ATA_STATIC_ID option, that is not applicable in = modern >> SATA world order. So at least device numbers will change. >>=20 >> Also you should take into account, that many people and some software >> already adapted to adaX names and change back will break POLA for = them. >=20 >=20 > I agree with what Alexander is saying, but I'd like to take it a step = further. We should all be using either mount-by-label, or be working to = introduce generic device names to GEOM. Right now, device names are an = implementation detail that have no functional use other than to = complicate the fstab. Disks exposed through the block layer are simply = direct-access block-array devices, nothing more. There's no functional = difference to the kernel or userland between ad, ar, da, aacd, mfid, = amrd, etc when it comes to reading and writing sectors off of them. But = yet we give them unique names and pretend that those names mean = something. We could give them all the name of "disk" and the system = would still function exactly that same. The name attributes are = interesting when it comes to doing out-of-band management, but it's also = trivial to create a human-readable map and a programatic API between the = generic name and the attribute name. Same goes for volumes labels, and = I'd almost argue that they're more powerful than generic device names. >=20 > In other words, "ada" isn't the problem here, it's that we all still = think in terms of the 1980's when systems didn't autoconfigure and = device names were important hints to system functionality. That time = has thankfully passed, and it's time for us to catch up. >=20 I agree that we need to catch up with something but we should have done = so a year ago. a) we MUST HAVE a transition scheme if we cam-base ATA by default. = Something that converts things automatically to whatever? That's not = been done in more than one year. It's not acceptable to update, reboot = and not find the root file system no matter what. We all agreed on that = back then. I do not really care how it's done. I have been testing cam based ata for a while now on the machines I = can cope with as a developer and even then I screwed the transition = partly two times in the last months. How's a normal user to do that = flawlessly? b) FYI: labels and stacked geoms do not work well together as you can = never detach providers cleanly then, which basically means you are at = risk of data loss with every reboot. I was told multiple times that = this is not fixable. If it is labels seem to be a great why to go. For = now I have to compile them out/disable them unfortunately so they are = not an option, and they'll be less so if the new installer also offers = gmirror, geli, ... installs. Give me a solution that works out of the box and I'll happily agree that = we switch. /bz --=20 Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family.