Accessing disks via their serial numbers.

[Pawel Jakub Dawidek]

On Mon, Jun 26, 2006 at 06:51:37AM +0000, Poul-Henning Kamp wrote:
> In message <20060626031636.GK82074 at funkthat.com>, John-Mark Gurney writes:
> 
> >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?
> 
> 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.
> 
> 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:
> 
> In addition to ad0, ad0s1 and ad0s1a we will then have label/SOMESERIAL,
> label/SOMESERIALs1, label/SOMESERIALs1a etc etc.
> 
> 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.
> 
> 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.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20060626/e4f3b849/attachment.pgp