From owner-freebsd-fs@FreeBSD.ORG Sun Feb 24 23:32:14 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F3459960 for ; Sun, 24 Feb 2013 23:32:13 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id C1242DDD for ; Sun, 24 Feb 2013 23:32:13 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 8A4AD3B9DD for ; Sun, 24 Feb 2013 15:32:10 -0800 (PST) From: "Ronald F. Guilmette" To: freebsd-fs@freebsd.org Subject: Hard drive device names... Serial Numbers? Date: Sun, 24 Feb 2013 15:32:10 -0800 Message-ID: <2511.1361748730@server1.tristatelogic.com> X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 23:32:14 -0000 Today I am diddling with a system of mine that already... before today... contained three SATA drives. I just now added to this system one old PATA drive I had lying around which I plan to use as a swap drive. The motherboard for the system in question has two of the older PATA ports (supporting up to four devices) and then also four SATA ports. It appears that the BIOS numbers the PATA devices first, and that FreeBSD just follows suit. Thus, for FreeBSD, whatever drive is the (PATA) primary master gets the name ada0, the primary slave, ada1, the secondary master ada2, the secondary slave ada3, and then the SATA ports get names ada4, ada5, etc. So anyway, adding the PATA drive to this system of course rendered everything I had previously had in my /etc/fstab suddenly incorrect. Fortunately, I anticipated this and was prepared to boot FreeBSD Live from a CD, and then go in and edit my /etc/fstab as necessary to adjust everything for the new hard drive numbers. This isn't the first time I've had to go through this process. It is always an annoyance. Up until today I was only dimly aware of the different approach described here: http://www.freebsd.org/doc/handbook/geom-glabel.html but today I was finally motivated to seek out and read the above page, which I have now done. Having now read all about temporary labels, permanment labels, and ufsids, and having noted the obvious drawbacks to each (including but not limited to the fact that these techniques generally only appear to be applicable exclusively to UFS file systems _and_ only recently created ones at that) I thought that I would take a second and ask about the general idea of using built-in hard drive serial numbers as a filesystem-independent and interface-independent way of identifying specific hard drive devices (and/or their sub-parts) e.g. within /etc/fstab. This idea seems so obviously that I am forced to assume that I'm probably far from the first person to have suggested and/or asked about it. So what gives? Why can't we have something like /dev/hdsn/ (hdsn == Hard Drive Serial Number) where a set of device numbers would automagically be created within that directory, all of whose names correspond to the actual hardware serial numbers of all currently attached hard drive type devices? (If just the serial numbers are not seen an being unique enough, I can imagine other unique or semi-unique properties of the drive being concatenated with the serial numbers.) It is easy also to envision obvious extensions to such a scheme. For example, a node named /dev/hdsn/1mgbhxed.s1a might represent the BSD "a" partition of MBR slice number 1 within the drive whose serial number is "1mgbhxed". Anyway, the whole point here is to have a naming convention that would work across both UFS and non-UFS filesystems, and also/even across both recently created UFS file systems which include the recently introduced ufsids as well as older pree-existing UFS filesystems. So, um, has any idea along these lines been disucssed previously? If so, what were the arguments for and against? Regards, rfg