Date: Wed, 20 Apr 2011 22:30:33 -0400 From: Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com> To: Scott Long <scottl@samsco.org> Cc: FreeBSD-Current <freebsd-current@freebsd.org>, Alexander Motin <mav@freebsd.org> Subject: Re: Switch from legacy ata(4) to CAM-based ATA Message-ID: <BANLkTi=V6OysSm61AXthkJg%2BuvnBi5hKVw@mail.gmail.com> In-Reply-To: <BCE89DC7-116D-48E1-BD86-DF986062B0CC@samsco.org> References: <4DAEAE1B.70207@FreeBSD.org> <20110420203754.GM85668@acme.spoerlein.net> <4DAF46F8.9040004@FreeBSD.org> <BCE89DC7-116D-48E1-BD86-DF986062B0CC@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 20, 2011 at 6:18 PM, Scott Long <scottl@samsco.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTi=V6OysSm61AXthkJg%2BuvnBi5hKVw>