From owner-freebsd-questions@FreeBSD.ORG Sat Jan 16 14:45:53 2010 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 356AB106568F for ; Sat, 16 Jan 2010 14:45:53 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from mx.utwente.nl (mx3.utsp.utwente.nl [130.89.2.14]) by mx1.freebsd.org (Postfix) with ESMTP id A849D8FC15 for ; Sat, 16 Jan 2010 14:45:52 +0000 (UTC) Received: from nox-laptop.student.utwente.nl (nox-laptop.student.utwente.nl [130.89.160.140]) by mx.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id o0GEjWHH012525; Sat, 16 Jan 2010 15:45:32 +0100 From: Pieter de Goeje To: freebsd-questions@freebsd.org Date: Sat, 16 Jan 2010 15:45:31 +0100 User-Agent: KMail/1.9.10 References: <201001152334.52978.jmc-freebsd2@milibyte.co.uk> In-Reply-To: <201001152334.52978.jmc-freebsd2@milibyte.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201001161545.31616.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: Mike Clarke Subject: Re: Newbie gmirror questions X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2010 14:45:53 -0000 On Saturday 16 January 2010 00:34:52 Mike Clarke wrote: > I'm about to upgrade to more disk space and I'm tempted use this as an > opportunity to get two disks and implement gmirror. Before I go ahead > there's a few aspects of mirroring I'm not sure about and would > appreciate some advice. > > I'm using grub for multi booting. Does this introduce any problems if I > want to boot into Windows or Linux on one of the other partitions? Gmirror stores the metadata at the last sector of each disk. So this shouldn't be a problem. But other operating systems might overwrite this data if you're not careful during the paritioning. > > The gmirror manpage describes the procedure for handling kernel dumps > using the prefer balance algorithm in the early stages of booting and > then switching to round-robin in the /etc/rc.local script. It then goes > on to say that "If on the next boot a component with a higher priority > will be available, the prefer algorithm will choose to read from it and > savecore(8) will find nothing". Does this only arise if I've made some > change to the configuration of the mirror between the dump and the > reboot or is there some instances when the priority automatically > changes? Priority never changes automatically. > > Some of the articles I've read about gmirror suggest setting the balance > to round-robin while others just leave this at the default setting of > split. Am I right in assuming that round-robin would give better > performance, and does it make much noticeable difference in real terms. > In particular am I likely to see a reduction in performance using > gmirror compared with what I would get with just a normal single disk. Assuming you have two or more regular HDDs, I can recommend updating to 8-STABLE and using the "load" algorithm. It has had some major improvements lately, and is now the default. It should give equal or better read performance in comparison to a single disk in all cases. The performance of "split" and "round-robin" is very dependent on the access patterns and stripe size (for split). > > Finally, recent articles say to set kern.geom.debugflags to 17 when > creating a mirror on a mounted drive while older articles say to set it > to 16. Although I'll probably be creating the mirror on my disks before > copying my system onto them so I don't really need to worry about > setting this flag but I'm curious to know the difference between using > the two values. The sysctl is a bitfield, so 17 (0x11) enables some extra stuff compared to 16 (0x10). See geom(4), section DIAGNOSTICS for more details. -- Pieter de Goeje