Date: Mon, 26 Jun 2006 10:00:38 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: John-Mark Gurney <gurney_j@resnet.uoregon.edu>, freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. Message-ID: <20060626080038.GA12511@garage.freebsd.pl> In-Reply-To: <33398.1151304697@critter.freebsd.dk> References: <20060626031636.GK82074@funkthat.com> <33398.1151304697@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
--J/dobhs11T7y2rNN
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Jun 26, 2006 at 06:51:37AM +0000, Poul-Henning Kamp wrote:
> In message <20060626031636.GK82074@funkthat.com>, John-Mark Gurney writes:
>=20
> >Can't we expand the disk api? add a const char *d_serial to the struct
> >disk, and have the disk api automaticly propegate the serial number up
> >to the geom layer?
>=20
> This is more or less what Pawel asked me for, and I am not at all
> convinced that is how we want to do it.
Actually I proposed the opposite: remove some d_* fields and make them
available via discussed mechanism.
> There are several attributes which could be relevant in a context
> like what Pawel proposes, the serial number (which one ? drive or
> media ?) the physical address cam-{bus,id,lun}, FC WWN's and so on.
>=20
> If we disregard mechanism for a moment, and assume that g_label gets
> hold of the info and creates label devices matching these various
> informations, then we have to address the problem of obsesity in
> the geom mesh:
>=20
> In addition to ad0, ad0s1 and ad0s1a we will then have label/SOMESERIAL,
> label/SOMESERIALs1, label/SOMESERIALs1a etc etc.
>=20
> The better way of implementing it is by using the devfs 'device-on-demand'
> facility to create symlinks to the geom_dev nodes based on specific
> lookups, that would not pollute /dev with nodes people don't really
> use and it would avoid the combinatorial explosion of the geom mesh.
>=20
> And this brings me to the next point: As nice as this feature
> sounds to begin with, is it really useful in practice ?
It is very useful in practice. We currently don't have such mechanism
and a lot of problems.
Why do you think glabel(8) (and previously geom_vol_ffs) is widely used?
Because people don't like surprises. Why do we have ATA_STATIC_ID?
So people don't have to fight with the box when they connect one more
disk making system not bootable.
I don't say that /dev/disk/MPB410X6G481KC is a nice name, nor is
/dev/disk/MPB410X6G481KCs1a, but this way people have something that
never change. You can always create a symlink
"usr -> disk/MPB410X6G481KCs1d" if you don't like the name.
Glabel(8) currently supports labeling any GEOM provider, but it steals
the last sector, which is not always acceptable.
> I'm against until somebody have explained what the use is, and if
> use is proven, it should be done with devfs device-on-demand(/cloning)
> instead of g_label.
I don't really care how we will make it visible for the user. This could
be devd(8) using some tool (diskinfo(8)?) to fetch serial number and
create a symlink to newly attached disk, but we need to have a general
mechanism inside the kernel for getting such informations.
--=20
Pawel Jakub Dawidek http://www.wheel.pl
pjd@FreeBSD.org http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
--J/dobhs11T7y2rNN
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)
iD8DBQFEn5QmForvXbEpPzQRApfsAKDoQDGnQV8QUvA23wXCSfFP7gW1CgCg0DeB
22r7mI9DIpxElN5qz+InuM4=
=xokh
-----END PGP SIGNATURE-----
--J/dobhs11T7y2rNN--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060626080038.GA12511>