From owner-freebsd-arch@FreeBSD.ORG Mon Jun 26 08:03:41 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 832A616A404 for ; Mon, 26 Jun 2006 08:03:41 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id C568343D7B for ; Mon, 26 Jun 2006 08:03:31 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id E540B51391; Mon, 26 Jun 2006 10:03:29 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id CB2B751307; Mon, 26 Jun 2006 10:03:23 +0200 (CEST) Date: Mon, 26 Jun 2006 10:00:38 +0200 From: Pawel Jakub Dawidek To: Poul-Henning Kamp Message-ID: <20060626080038.GA12511@garage.freebsd.pl> References: <20060626031636.GK82074@funkthat.com> <33398.1151304697@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline In-Reply-To: <33398.1151304697@critter.freebsd.dk> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: John-Mark Gurney , freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 08:03:41 -0000 --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--