Date: Tue, 10 Nov 2009 20:02:13 +0100 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Ross Gohlke <ross@grinz.com> Cc: freebsd-geom@freebsd.org Subject: Re: gjournal questions and observations Message-ID: <20091110190213.GB3194@garage.freebsd.pl> In-Reply-To: <4AF64F7D.8020802@grinz.com> References: <4AF64F7D.8020802@grinz.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Y7xTucakfITjPcLV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 07, 2009 at 10:56:29PM -0600, Ross Gohlke wrote: > KUDOS > Congratulations to all GEOM contributors. While I am new to GEOM, so far= =20 > I am very impressed with the way it is designed and the capabilities=20 > (both realized and anticipated) the design offers. >=20 > QUESTIONS > 1. What is the best way to journal whole disks whose slices (without=20 > partitions) are used by gconcat and gmirror? Does the same apply for gvin= um? > The ultimate scenario seems to be journaling another GEOM class such as= =20 > gmirror because gjournal handles the synchronization of all mirror=20 > consumers. You can turn off autosync on the mirror, thus saving CPU=20 > cycles and improving disk access. (Am I right?) You should always gjournal top-most provider, so you always put UFS on top of <name>.journal provider. Don't do anything with <name>.journal besides of file system configuration. > 2. How should gjournal and gmirror be configured when the journal is=20 > outside, instead of inside, the mirror? > The above scenario only seems possible if a) you are willing to journal= =20 > slices, which is not best practice [1] [2] or b) you use whole disks in= =20 > your mirrors, which is not very realistic. > Further I am on PowerPC and don't even have bsdlabel, so journaling=20 > slices and mirroring partitions is not an option anyway. > My thought was to journal each disk separately, outside the mirror, and= =20 > keep autosynchronization on for the mirror. >=20 > [1]=20 > http://lists.freebsd.org/pipermail/freebsd-questions/2008-April/173501.ht= ml > [2]=20 > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2008-11/msg0024= 7.html See above. You can safely gmirror disks, slices or partition and put gjournal on top of gmirror and file system on top of gjournal. > 3. What is the best way to completely remove a whole disk journal such=20 > that re-issuing > % gjournal label /dev/ad0 > does not require -f? > I have tried gpart destroy/create and newfs -E. I have not tried=20 > blanking the whole disk with dd, nor have I tried newfs -E on the whole= =20 > disk. gjournal stop <name>.journal (or <name>); gjournal clear <name> > 4. Does it matter whether gjournal is loaded when gjournal label is issue= d? > Originally I was journaling slices, and I was unable to properly stop a= =20 > particular slice. > % gjournal stop ad0s6.journal > % gjournal list > Showed the slice still loaded, but under a different name: > ie, ufsid/48x6x1bxc39394x7 You provider is accessible by few different names. This ufsid/ thing (which I don't like) is one of them. Once you stop gjournal on one name it is recreated using another name. Besides of using -h option to gjournal label and hardcoding provider name there is not much we can do. > While gjournal man page states journaling an existing file system=20 > REQUIRES a separate device for storing the journal, it appears to work=20 > without specifying a second device. At least > % gjournal label -f /dev/ad0 > seems to work, using the end of /dev/ad0 to store the journal whether a= =20 > slice occupies those sectors or not. (Consequently, trying to gmirror=20 > the last slice when it occupies journal sectors will fail.) It will eventually work until your UFS will start to use space gjournal is using for journal. Absolutely don't do that. Its like creating 4GB file system on 3GB provider - at some point you will need the missing 1GB.. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --Y7xTucakfITjPcLV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFK+bi1ForvXbEpPzQRAp5jAKDkRwmq4/XZpAnuMUH+P2I55i7HXgCg0qUh 8HZEy8nEoesLwXkwcuiKus4= =qo5a -----END PGP SIGNATURE----- --Y7xTucakfITjPcLV--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091110190213.GB3194>