Re: Switch from legacy ata(4) to CAM-based ATA

On Wed, Apr 20, 2011 at 6:18 PM, Scott Long <scottl_at_samsco.org> wrote:

> On Apr 20, 2011, at 2:50 PM, Alexander Motin wrote:
> > Ulrich Spörlein 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
> >> ...
> >>
> >> 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 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.
> >
> > 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 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.
>
> 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.
>
> Scott
>
>


Defining disk units/partitions by labels is a vital requirement , especially
, 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 USB
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 .



Thank you very much .



Mehmet Erol Sanliturk