Date: Wed, 28 Mar 2007 14:48:32 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Eric Anderson <anderson@freebsd.org> Cc: Ivan Voras <ivoras@fer.hr>, freebsd-geom@freebsd.org Subject: Re: Geom_label and multiple devices Message-ID: <20070328124832.GB35749@garage.freebsd.pl> In-Reply-To: <460A6075.7000302@freebsd.org> References: <eudglr$mpi$1@sea.gmane.org> <460A6075.7000302@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--KsGdsel6WgEHnImy Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 28, 2007 at 07:32:53AM -0500, Eric Anderson wrote: > 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=20 > >apply 100% to UFS and other filesystems' labels (except if there's a way= to identify different file systems by their superblock, for example timest= amp of creation?), but=20 > >in case of "manual" labels, if the unique ID matches and the label strin= g 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 (tho= ugh I don't remember the=20 > >conclusions). It would be useful if geom_label would work the same as ge= om_multipath in this case (i.e. failover to "next" device, add new devices = with same label+id to=20 > >the pool), or even if geom_multipath were merged in geom_label. > >Comments? >=20 >=20 > I think that the duplicate label case is not really the same as multipath= =2E I see your point, but the duplicate label issue is more of a cause fr= om mistake rather than=20 > intention. Yeah. When I see duplicated labels, I don't want to show them both with some random names that nobody expect. And think here about automatic processing, not that administrator can take a look and find new name. I can do two things: 1. Present one of those labels. 2. Stop the system (panic?), because it's just administrator fault (misconfiguration). I'd prefer 2, but it's too cruel. Administrators make mistakes and we have some garbage to clean still (eg. 'c' partition). That's why I decided to go with 1. > 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=20 > labeled my root partition /dev/label/root. If I have a compact flash plu= gged in that I'm working on for a small embedded device, I also need it nam= ed /dev/label/root, even=20 > though I'm already using that label. I want to be able to reboot my lapt= op with the compact flash inserted still, without it possibly booting off t= he flash instead. To=20 > 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 t= his device'. A '0'=20 > would mean no priority given, and any number greater than 0 is less prior= ity. That way admins could mark their labels and allow certain devices to = be forced more important=20 > than others. Comments? I like this idea, but it can only be used for glabel's native labels. You can't use the same method for filesystem volume names, and those are more often used than glabel's native labels. Don't read me wrong, I still like your idea and would be glad to commit something like this. Care to provide a patch?:) --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGCmQgForvXbEpPzQRAj9mAJ9ZGU8dDyoL0pqO5sZ0T3KCwoBcsgCcCglG uGhLjdWC154HgMb6pbkMQek= =a2mv -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070328124832.GB35749>