Re: Accessing disks via their serial numbers.

In message <20060626031636.GK82074@xxxxxxxxxxxx>, 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.

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 ?

I suspect that the proponents of this scheme will object to my proposal
because they can not do a "ls /dev/mumble/*" to get a list of disk
serial numbers, and if so, that dooms the proposal: If the only objective
is to get a list of serial numbers, then this is not how it should be
done, instead we should add a real VPD registry to the kernel.

Summary:

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.

Poul-Henning

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@xxxxxxxxxxx | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Accessing disks via their serial numbers.
    ... You could even order and eat a pizza while a 3B700 rebuilt its ... that I had thought about going to /dev/disk%d for GEOM. ... use by including GEOMs in the kernel or loading them at boot time. ... My main objection to what Pawel proposes is that it is not what ...
    (freebsd-arch)
  • Re: Accessing disks via their serial numbers.
    ... 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 ... You can always create a symlink ...
    (freebsd-arch)
  • tunefs on a mounted file system?
    ... tunefs should work on a mounted file system ... devfs on /dev ... I think this may have something to do with GEOM access modes: ... Geom name: ad0 ...
    (freebsd-current)