Date: Sat, 18 Feb 2012 17:17:54 +0100 From: Peter Maloney <peter.maloney@brockmann-consult.de> To: freebsd-stable@freebsd.org Subject: Re: New BSD Installer Message-ID: <4F3FCF32.7060501@brockmann-consult.de> In-Reply-To: <20120217210250.GA77709@sputnjik.localdomain> References: <E1RyLjZ-0009kp-GN@dilbert.ingresso.co.uk> <4F3E89E3.3060608@quip.cz> <20120217210250.GA77709@sputnjik.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
Can't you just create a slice, make a gmirror out of your slice, and then slice your mirror again? This is the way you would do it for mdadm on Linux (probably with swap outside the mirror). (and in the old days you would have 2 copies of /boot non-mirrored; dunno about today) Am 17.02.2012 22:02, schrieb Nikola Pavlović: > On Fri, Feb 17, 2012 at 06:09:55PM +0100, Miroslav Lachman wrote: >> Pete French wrote: >>> Should this not be the recommended way of doing things even for MBR >>> disks ? I have a lot of machines booting from gmirror, but we always >>> do it by mirroring MBR partitions (or GPT ones). I cant see why you would >>> want to do it the other way round in fact. It doesnt gain you anything >>> does it ? >> Yes it does? Am I the only one person on the whole earth seeing the >> big difference in easy setup of mirroring two drives instead of many >> individual partitions? >> > You are not. In fact, the current situation is ironic considering the > following passage from geom(4): > > "Compared to traditional “volume management”, GEOM differs from most and > in some cases all previous implementations in the following ways: > > [...] > > " · GEOM is topologically agnostic. Most volume management implementa‐ > tions have very strict notions of how classes can fit together, very > often one fixed hierarchy is provided, for instance, subdisk - plex - > volume. > > [...] > > "Fixed hierarchies are bad because they make it impossible to express > the intent efficiently. In the fixed hierarchy above, it is not possible to > mirror two physical disks and then partition the mirror into subdisks, > instead one is forced to make subdisks on the physical volumes and to > mirror these two and two, resulting in a much more complex configuration. > GEOM on the other hand does not care in which order things are done, the > only restriction is that cycles in the graph will not be allowed." > > So there, even the docs agree that mirror-partition ordering is not so > outlandish as some are suggesting. IIRC, that's the way gmirror-ing is > described in the Handbook as well. > > > I would like to be understood that I didn't write this just to make a > smartass comment--I understand the difficulty and that the regression is > unintentional (as they all are). But on the other hand, I don't think > it's now OK to just tell people something like "oh well, you are all > better of with partition-mirror order anyway, problem solved". It's true > that it can be better sometimes, but that's not the point. The point > is, specifically, you are now forced to set up mirroring in a way that > may not suit your needs or you have to start jumping through hoops (the > workaround with one big GPT and bsdlabel inside that doesn't seem *too* > bad though), and generally, an important aspect of GEOM is now formally > broken. > > It must be fixed IMO, no ifs and buts, but OTOH people affected by > this should also have a certain degree of patience and understanding as > longs as the whole thing is not swept under the rug. > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F3FCF32.7060501>