From owner-freebsd-geom@FreeBSD.ORG Wed Mar 28 12:33:04 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F41EF16A400 for ; Wed, 28 Mar 2007 12:33:03 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id D50B513C46E for ; Wed, 28 Mar 2007 12:33:03 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l2SCWrM6064122; Wed, 28 Mar 2007 07:32:53 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <460A6075.7000302@freebsd.org> Date: Wed, 28 Mar 2007 07:32:53 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: Ivan Voras References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/2946/Wed Mar 28 04:36:58 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=8.0 tests=BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-geom@freebsd.org Subject: Re: Geom_label and multiple devices X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 12:33:04 -0000 On 03/28/07 05:39, Ivan Voras wrote: > I've just thought of something - the situation where geom_label detects > multiple "same" labels is actually very similar to that of > geom_multipath. Obviously this doesn't apply 100% to UFS and other > filesystems' labels (except if there's a way to identify different file > systems by their superblock, for example timestamp of creation?), but in > case of "manual" labels, if the unique ID matches and the label string > matches, it's probably the same device. > > Currently, geom_label discards "additional" devices with the same label, > and I remember there was a discussion about if that should be changed > (though I don't remember the conclusions). It would be useful if > geom_label would work the same as geom_multipath in this case (i.e. > failover to "next" device, add new devices with same label+id to the > pool), or even if geom_multipath were merged in geom_label. > > Comments? > I think that the duplicate label case is not really the same as multipath. I see your point, but the duplicate label issue is more of a cause from mistake rather than intention. To me, these are the cases that could arise for geom_label in the duplicate label case: 1) Same device, multiple paths. Can be detected like you mention above (checking superblocks). That works fine for UFS but not everything else. This case must be certain that it *is* the same device. This is hard to do. 2) Possibly same device with multiple paths. Maybe there's no file system on the device yet, or geom_label can't determine if it's the same device (sizes, etc all match exactly, but it's not 100% certain). 3) Definitely *not* the same device. For (1), once geom_label is certain it is truly the same path, ignore the additional duplicate labels found, but print a warning like: "geom_label: duplicate /dev/... found: multiple paths for same label." "geom_label: removing subsequent duplicates for /dev/..." For (2), we something similar, but rename any duplicates so the administrator can still deal with the duplicate via a label. That helps the admin determine what really went on. Something like this: "geom_label: duplicate /dev/...: possible multiple paths for same label." "geom_label: renaming duplicate label /dev/... to /dev/...-DUP1" And for (3), the result is the same as (2), except the error message is different: "geom_label: duplicate /dev/...: SAME LABEL FOR DIFFERENT DEVICES!" "geom_label: renaming duplicate label /dev/... to /dev/...-DUP1" Maybe it would be a good idea to allow a priority value in the geom_label meta data so that an admin could prioritize his labels. For instance, on my laptop, I have labeled my root partition /dev/label/root. If I have a compact flash plugged in that I'm working on for a small embedded device, I also need it named /dev/label/root, even though I'm already using that label. I want to be able to reboot my laptop with the compact flash inserted still, without it possibly booting off the flash instead. To protect against that, I could prioritize my internal hd's 'root' labeled device to a priority of '1', which means 'nothing is higher priority than this device'. A '0' would mean no priority given, and any number greater than 0 is less priority. That way admins could mark their labels and allow certain devices to be forced more important than others. Comments? Eric