From owner-freebsd-current@FreeBSD.ORG Thu Apr 21 04:00:29 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 8514810656A5; Thu, 21 Apr 2011 04:00:29 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1A0DD8FC30; Thu, 21 Apr 2011 04:00:28 +0000 (UTC) Received: by iwn33 with SMTP id 33so1572785iwn.13 for ; Wed, 20 Apr 2011 21:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:x-openpgp-key-id:x-openpgp-key-fingerprint :x-openpgp-key-url; bh=hz/ErYxVv7WvD+6s6Tbu+SAeCFDqf1ub0KQQjYAMnaQ=; b=ZgTVY4R4zXXKYk4NNlaF1d1ZY3gVJBj5vFbmr5Abhkf+vCNUYpUlCXX/WTxlmXXgKB EDeXI+BNOdgGGsmYsQexI1JM2mjaWd9mM/2QWJMgYwD79zh26A7Z9Lz+z5DUdbShMhxd 2HoISPIXMhVmF0KYZmryOAhVxDPjnH9yi08mg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-openpgp-key-id :x-openpgp-key-fingerprint:x-openpgp-key-url; b=sVC7lGZGuv3kn6ji4ktWG5TNIXpZPr7d2DFdbEQZB1ScdqJ2C2lYAkt0+W/AgHga9W G+CJLctU87ocev0pJ1xQBJRKO9IMpYg7WFC40puoWZDLwJmd2r43fji0hu7OnII55mgS kmbpvfdeKCeIQ7YYbTrp4ZGFPw1CHla9RzS2Q= Received: by 10.42.83.194 with SMTP id i2mr2061475icl.305.1303358426264; Wed, 20 Apr 2011 21:00:26 -0700 (PDT) Received: from DataIX.net (adsl-99-190-84-116.dsl.klmzmi.sbcglobal.net [99.190.84.116]) by mx.google.com with ESMTPS id vr5sm551357icb.12.2011.04.20.21.00.24 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Apr 2011 21:00:24 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p3L40K4a095461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Apr 2011 00:00:21 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p3L40KVV095460; Thu, 21 Apr 2011 00:00:20 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Thu, 21 Apr 2011 00:00:19 -0400 From: "J. Hellenthal" To: Mehmet Erol Sanliturk Message-ID: <20110421040019.GA91477@DataIX.net> References: <4DAEAE1B.70207@FreeBSD.org> <20110420203754.GM85668@acme.spoerlein.net> <4DAF46F8.9040004@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E X-OpenPGP-Key-URL: http://bit.ly/0x89D8547E 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 04:00:30 -0000 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 20, 2011 at 10:30:33PM -0400, Mehmet Erol Sanliturk wrote: >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=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 th= ing >> >> ... >> >> >> >> 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 loadi= ng >> > 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 complica= te >> the fstab. Disks exposed through the block layer are simply direct-acce= ss >> 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 com= es >> 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 a= ll >> 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 g= oes >> 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 thi= nk >> 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 , especial= ly >, 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 U= SB >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 = is >preventing the boot of the system at the beginning . > Personally Id love to see a structured layout of devices just for type disk whether it be USB ATA SCSI... and be able to attach all those to one virtual layer that organizes them into, Where (diskN) is the virtual layer that works very much like what the wlan(4) devices do for wireless adapters but transparent to the user and the user wouldn't have to worry about "if I'm using this driver then WTF is my disk called now" /dev/disk0/ [label] [guid] [ufsid] [zfsid] [gptid] [slice1 or part1] And [label] could be anywhere from msdosfs to ufs with some sort of priority chain that is followed to determine which label should be showing. For instance if it is a msdosfs and no other generic label has been set then use the msdosfs label else do not show the label. Of course other prevention would need to be taken to prevent collision of purposeful user corruption of duplicate labels but it at least provides a predictable location as to which the disks appear under the device filesystem. Just some thoughts but I'm sure this thread is far beyond what it was originally meant to be about so Ill leave it there. --=20 Regards, J. Hellenthal WWJD --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNr6vTAAoJEJBXh4mJ2FR+IEsIAJAqVPwim9NEc2p8LDEVFveH QrNOCU1UUJdx9wu7/sd4iXvhNmLGauDWc8zIClb4iHGVJvYre5SzYKiOe8AnC3GF HGsLuilihraWLloGD7y1UgH7D6eaw7kG6Qd90r+PsDPGxoHOva2beMYrH0SvhDcu qlbFsDQDz8Pm2LzEguIziIcTx5MWaMTGsGSUomXRei86a04Hu2DgJ48jucxmbVS+ 3/8b1qhXn+RKtxm4sp6cK/OW0ngrXfOVL5diUatl3ADAdcDUpPVVlb705CE0gA+O VG19UbxxISQYa3dk0SN/qyczJkJ8uKV7XZf0trf7N4wESTgWqYI2Px0/XVkvTn4= =wE1O -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs--