Date: Fri, 09 Feb 2007 23:05:01 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Marcel Moolenaar <xcllnt@mac.com> Cc: geom@FreeBSD.org Subject: Re: g_part partition tool -- some logistic questions Message-ID: <6781.1171062301@critter.freebsd.dk> In-Reply-To: Your message of "Fri, 09 Feb 2007 11:27:33 PST." <D63AC737-8D1B-4835-BCC5-52E055A702FF@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <D63AC737-8D1B-4835-BCC5-52E055A702FF@mac.com>, Marcel Moolenaar wri tes: >The first question relates to finding and presenting the right >devices/providers to the users. What I don't want is present, >for example, ad0 and ad1 if they are part of a mirror. I'd like >to present the mirror to the user. The same applies to other >GEOM classes. > >Is there a generic or established way to walk the GEOM tree >(obtained by geom_gettree()), and find the real or true virtual >storage providers that takes the hierarchy into account? There are no providers that are more "real" or "true" than others, they are all "just" providers. If you want to add a "desirability" property to the providers, then I'm all for it, provided you explain up front how you expect it to actually work. If you have bsd(mirror(ad0,ad1)), then the BSD parts should be more desirable than the mirror or the disks. If on the other hand you have mirror(bsd(ad0),bsd(ad1)), then the mirror should be more desirable than the bsd's and the disks. It follows from this that just assigning a desirability to a class or an instance is not trivial. In general however, I think we can do a pretty good approximation to "DWIM" by using the rank property, because in general people don't stack things up if they don't want to get upwards. So you may want to try something like pruning everything but the highest ranking leaf providers in each subtree and see where that gets you. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6781.1171062301>