Date: Thu, 21 Apr 2011 07:51:56 +0000 From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: FreeBSD-Current <freebsd-current@freebsd.org> Subject: Re: Switch from legacy ata(4) to CAM-based ATA Message-ID: <DACA5DEF-C004-4818-B658-21045582E480@lists.zabbadoz.net> 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 Apr 20, 2011, at 10: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 =
thing
>>> ...
>>>=20
>>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>=20
>=20
> 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.
>=20
> 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.
>=20
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
--=20
Bjoern A. Zeeb You have to have visions!
Stop bit received. Insert coin for new address family.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DACA5DEF-C004-4818-B658-21045582E480>