From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 02:30:35 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 77D02106564A; Thu, 21 Apr 2011 02:30:35 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 0D4068FC17; Thu, 21 Apr 2011 02:30:34 +0000 (UTC) Received: by qyk35 with SMTP id 35so2708074qyk.13 for ; Wed, 20 Apr 2011 19:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=f1XxeWsFp3KMPlggLCThH4vEOA7OwBjSrldPAkZ9GVU=; b=jDq1mJZgwq839+2nfQP3b7txKXNo+XX/yHpAuPkLUg9HWsxWJgcfBSc1cS6mF9BF9E wNiWYy8uYotBnQoUmOHiTJ7nSOVetfkbNaTMVYmgT+Cbba3ywjlwW7Hh2HjfMmVK2FIi 8/lLVh3Q4SsJiEnGmKkhg/YZoxJ2lOcoM+Zqo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=V/Fm7Ge7pVD3/IhYIDpq8OzMEewXdMIGqiATWSnbzXlbkerhE5BUrltgwKK+Ssfli6 5t/TdtTD9VgRCDkB0QJUPUiG47sSqX2zXrhbmULwKHXWo8MxFW/vDdyw1KG/dyEeVqPy VeYwmsUX5L5Xs9KUkfVdVVCMn5IDebfaw7GKM= MIME-Version: 1.0 Received: by 10.224.213.193 with SMTP id gx1mr5194199qab.44.1303353034119; Wed, 20 Apr 2011 19:30:34 -0700 (PDT) Received: by 10.224.89.72 with HTTP; Wed, 20 Apr 2011 19:30:33 -0700 (PDT) In-Reply-To: References: <4DAEAE1B.70207@FreeBSD.org> <20110420203754.GM85668@acme.spoerlein.net> <4DAF46F8.9040004@FreeBSD.org> Date: Wed, 20 Apr 2011 22:30:33 -0400 Message-ID: From: Mehmet Erol Sanliturk To: Scott Long Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD-Current , Alexander Motin 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 02:30:35 -0000 On Wed, Apr 20, 2011 at 6:18 PM, Scott Long wrote: > On Apr 20, 2011, at 2:50 PM, Alexander Motin wrote: > > Ulrich Sp=C3=B6rlein 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 thi= ng > >> ... > >> > >> 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. > > > > Stacks do can run in parallel, and it really happens when people loadin= g > > 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. > > > > 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. > > > > 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. > > > 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 complicat= e > the fstab. Disks exposed through the block layer are simply direct-acces= s > block-array devices, nothing more. There's no functional difference to t= he > kernel or userland between ad, ar, da, aacd, mfid, amrd, etc when it come= s > 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 al= l > 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 go= es > for volumes labels, and I'd almost argue that they're more powerful than > generic device names. > > In other words, "ada" isn't the problem here, it's that we all still thin= k > 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. > > Scott > > Defining disk units/partitions by labels is a vital requirement , especiall= y , because of external devices such as USB sticks , USB attached disks and other disk-like units ( Compact Flash , etc. ) . When these units are attached , let's say into USB 0 , USB 1 , and so on , and we expect that US= B stick is attached into USB 0 is da0 is NOT valid because attaching an external HDD is changing numbering of attached parts on the fly , and making them unusable . When there is a boot USB stick in slot USB 0 , and a HDD in slot USB 1 ( or larger number ) is NOT allowing boot from USB stick = , because of this drive number change . To solve this problem , it is necessary to mount units from fstab with respect to their labels or ( their physical ports which NOT desirable ) instead of /dev/..... definitions . FreeBSD 9.0-Current snapshots installed by bsdinstall by Nathan Whitehorn is also using /dev/... definitions in fstab and this structure is making such installs to USB devices unusable . Perhaps there are work arounds , but having a smoothly working default structure is most preferably one . At least , a choice may be made in fstab to allow either of these definitions : Current /dev/ system : device /dev/da0 ... device /dev/da1 ... and others , OR , attachment based on physical structure : port USB0 port USB1 port cd0 port SATA0 port SATA1 port PATA2 OR , or attachment based on labels , physical attachment point is NOT relevant for the user : label FreeBSD_8_2_Root ... label FreeBSD_8_2_Usr .... and others . This selection may be made during installation . I am trying to understand a way to design a PHYSICALLY secure FreeBSD , but encountering the above serious problem as arbitrary drive numbering which i= s preventing the boot of the system at the beginning . Thank you very much . Mehmet Erol Sanliturk