Date: Wed, 21 Apr 2010 18:52:28 +1000 From: Andrew Reilly <areilly@bigpond.net.au> To: David N <davidn04@gmail.com> Cc: freebsd-fs@freebsd.org Subject: Re: gjournal: what is it good for? Message-ID: <20100421085228.GA27892@duncan.reilly.home> In-Reply-To: <r2q4d7dd86f1004210105o1ab574b7g350822e9bed99b82@mail.gmail.com> References: <20100418235428.GC4620@duncan.reilly.home> <20100420234447.GB1737@garage.freebsd.pl> <20100421011834.GA24928@duncan.reilly.home> <k2q4d7dd86f1004201920s2139647aja783e86e266153ca@mail.gmail.com> <20100421024803.GA25701@duncan.reilly.home> <r2q4d7dd86f1004210105o1ab574b7g350822e9bed99b82@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 21, 2010 at 06:05:02PM +1000, David N wrote: > On 21 April 2010 12:48, Andrew Reilly <areilly@bigpond.net.au> wrote: > > On Wed, Apr 21, 2010 at 12:20:46PM +1000, David N wrote: > >> What kind of disks are you using? Or what hardware are you using? > > > > Several: main /usr is on a gjournal on top of a gmirror over a > > pair of Samsung 1TB 3.5" SATA drives, but I have other gjournals > > on a 750G WD SATA, a 1.5T Seagate and another 1TB WD MyBook > > firewire unit. There is brokenness in the firewire connection > > that results in me always coming up manually through single-user > > mode, at the moment. In single user mode pilot error is > > sufficient to account for the problems that I was having with > > mount vs fsck of the gjournalled drives, I'm fairly sure. > Wow, thats a setup. More an artifact of fair old age and accretion than design... > I have a few more questions. > > Your first email, you mentioned gjournal overflow panics. Have you fixed that? No: I've avoided it, at risk of incomplete backups, by leaving the -L (snapshot) option off my backup "dump" calls. I'm fairly certain that I can generate those panics on demand, now that I know what's causing them. (I prefer not to, of course, this machine is in constant use.) > I see you are gmirroring the slices, when you did the gmirror + > gjournal slice, did you check the bsdlabel? sometimes it doesn't > report the right block size, and the disk + journal overlap. I had > this happen to me on my first setup which resulted in the overflow > panics. Not sure about that. All of my disks only have one bsdlabel, on the raw provider. I fdisk -BI; bsdlabel -w -B and then newfs the ...s1a partition, as a general rule. Now that I'm running gjournal, that's fdisk; bsdlabel; gjournal label ...; newfs ...s1a.journal. There isn't a label between the gjournal and the file system. In the case of my main, gmirrored disk pair, I bsdlabel -e'd after the "use whole disk" standard procedure and made liberal use of "*" wildcards to make sure that bsdlabel did the right thing. I was *very* glad when I didn't have to muck about calculating sector offsets any more. I have my mirror'd pair layered: fdisk; bsdlabel; gmirror on ad[46]s1a, ad[46]s1d and ad[46]s1e, separately, rather than mirroring the raw ad4/ad6 pair and then bsdlabeling the resulting mirror because I couldn't see the point in swapping to a mirror. So I swap to ad4s1b and ad6s1b independently. So I have root on mirror/gm0a (no soft-updates), var on mirror/gm0d (with soft-updates), and a gjournal on mirror/gm0e, with a newfs -J partition on mirror/gm0e.journal > Its not as easy as a > gmirror label ... > gjournal label ... > You gotta check the bsdlabel each time to make sure the c slice and > additional slices are the correct size. I didn't think that GEOM layers needed to have a bsdlabel each, and newfs is happy enough (I think) to sit on an unlabelled GEOM provider. Certainly the examples in the gjournal, gmirror and mdconfig man pages seem to suggest that newfs'ing straight onto one of them is the way to go. > If you do decide to do it again, gpt made it really easy. What's a gpt? Neither man nor bash know about it on my system. > Did you use newfs -J to format the slices/journal? Yup. Thanks for the help and suggestions! Cheers, -- Andrew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100421085228.GA27892>