Date: Wed, 28 Mar 2007 08:07:47 -0500 From: Eric Anderson <anderson@freebsd.org> To: Pawel Jakub Dawidek <pjd@freebsd.org> Cc: Ivan Voras <ivoras@fer.hr>, freebsd-geom@freebsd.org Subject: Re: Geom_label and multiple devices Message-ID: <460A68A3.1060605@freebsd.org> In-Reply-To: <20070328124832.GB35749@garage.freebsd.pl> References: <eudglr$mpi$1@sea.gmane.org> <460A6075.7000302@freebsd.org> <20070328124832.GB35749@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On 03/28/07 07:48, Pawel Jakub Dawidek wrote: > 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 >>> 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. > > 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. The problem with 2 is that any random person walking up to your system or handing you a usb stick labeled 'incorrectly' could panic your system. Not a good thing. >> 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? > > 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. This is true, and I thought of that. Since the main case is UFS2, we could possibly (dare I suggest) use one of the empty slots in the UFS superblock to put in a priority value, and add an option to tunefs/newfs to set that value. The superblock is already tasted to find the label name, so while we're there, just grab the priority and use the same values as mentioned above. That shouldn't break any backwards compatibility either. That doesn't solve the msdosfs case, but that is probably a lot less common, and possibly less detrimental to a system compared to UFS. > Don't read me wrong, I still like your idea and would be glad to commit > something like this. Care to provide a patch?:) I'll give it a shot - but give me some time, I only have about 5 mins of free time per day. :) Eric
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?460A68A3.1060605>