Accessing disks via their serial numbers.
Poul-Henning Kamp
phk at phk.freebsd.dk
Mon Jun 26 21:03:34 UTC 2006
In message <20060626194707.GA44234 at psconsult.nl>, Paul Schenkeveld writes:
>Back in the old days the AT&T 3B [...]
Yes, everything was better in the good old days, wasn't it ? :-)
You could even order and eat a pizza while a 3B700 rebuilt its
kernel, these days you can barely make a decent cup of tea :-)
Anyway, seriously:
I am not against change in this area, but I somewhat fear having a
multiplicity of philosophies about it is going to help us.
Justin@ renamed /dev/sd%d to /dev/da%d when he introduced CAM and
sos@ renamed /dev/wd%d to /dev/ad%d with ATA, and both of them
got so much grief for it that I didn't even mention to anybody
that I had thought about going to /dev/disk%d for GEOM.
Considering that all other contemporary filesystems is moving in
the direction of on-media identification, I think that is the only
sane direction for us to move as well.
UFS labels takes us a long way in that direction.
>So having a choice between several different schemes is perhaps the best
>way to keep many sysadmins happy.
... and drive the documentation people insane.
>Like /dev/[r]dsk/c0b0t0d0l0s1a as in SysV ;-(
There were a certain level of madness to that method, and vice versa,
so I wouldn't entirely object, provided we don't cause regression
in too many personal traumas :-)
>Having a choice is good, especially if one can choose which scheme to
>use by including GEOMs in the kernel or loading them at boot time.
If done in moderation: yes.
>The
>current default of ad*, da* and so on could (IMO should) stay and remain
>the default to not violate POLA.
Agreed.
My main objection to what Pawel proposes is that it is not what
anybody really want. Pawel sees it as a legitimate quick fix for
60% of the itch people want scratched, I want the percentage to
be a fair bit higher than that.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
More information about the freebsd-arch
mailing list