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

On Apr 20, 2011, at 10:18 PM, Scott Long 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.
> 

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

-- 
Bjoern A. Zeeb                                 You have to have visions!
         Stop bit received. Insert coin for new address family.