good/best practices for gmirror and gjournal on a pair of disks? - FreeBSD

This is a discussion on good/best practices for gmirror and gjournal on a pair of disks? - FreeBSD ; I've been running many of my systems for some time now using gmirror on a pair of identical disks, as described by Ralf at: http://people.freebsd.org/~rse/mirror/ Each disk has single slice that covers almost all of the disk. These slices are ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: good/best practices for gmirror and gjournal on a pair of disks?

  1. good/best practices for gmirror and gjournal on a pair of disks?


    I've been running many of my systems for some time now using gmirror
    on a pair of identical disks, as described by Ralf at:

    http://people.freebsd.org/~rse/mirror/

    Each disk has single slice that covers almost all of the disk. These
    slices are combined into the gmirror device (gm0), which is then
    carved up by bsdlabel into gm0a (/), gm0b (swap), gm0d (/var), gm0e
    (/tmp), and gm0f (/usr).

    My latest machine is using Seagate 1TB disks so I thought I should add
    gjournal to the mix to avoid ugly fsck's if/when the machine doesn't
    shut down cleanly. I ended up just creating a gm0f.journal and using
    it for /usr, which basically seems to be working.

    I'm left with a couple of questions though:

    - I've read in the gjournal man page that when it is "... configured
    on top of gmirror(8) or graid3(8) providers, it also keeps them in
    a consistent state..." I've been trying to figure out if this
    simply falls out of how gjournal works or if there's explicity
    collusion with gmirror/graid3 but can't come up with a
    satisfactory explanation. Can someone walk me through it?

    Since I'm only gjournal'ing a portion of the underlying gmirror
    device I assume that I don't get this benefit?

    - I've also read in the gjournal man page "... that sync(2) and
    fsync(2) system calls do not work as expected anymore." Does this
    invalidate any of the assumptions made by various database
    packages such as postgresql, sqlite, berkeley db, etc.... about
    if/when/whether their data is safely on the disk?

    - What's the cleanest gjournal adaptation of rse's
    two-disk-mirror-everything setup that would be able to avoid
    tedious gmirror sync's. The best I've come up with is to do two
    slices per disk, combine the slices into a pair of gmirror
    devices, bsdlabel the first into gm0a (/), gm0b (swap), gm0d
    (/var) and gm0e (/tmp) and bsdlabel the second into a gm1f which
    gets a gjournal device.

    Alternatively, would it work and/or make sense to give each disk a
    single slice, combine them into a gmirror, put a gjournal on top
    of that, then use bsdlabel to slice it up into partitions?

    Is anyone using gjournal and gmirror for all of the system on a pair
    of disks in some other configuration?

    Thanks,

    g.
    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  2. Re: good/best practices for gmirror and gjournal on a pair of disks?

    Adam McDougall writes:
    > George Hartzell wrote:
    > >[...]
    > > - I've read in the gjournal man page that when it is "... configured
    > > on top of gmirror(8) or graid3(8) providers, it also keeps them in
    > > a consistent state..." I've been trying to figure out if this
    > > simply falls out of how gjournal works or if there's explicity
    > > collusion with gmirror/graid3 but can't come up with a
    > > satisfactory explanation. Can someone walk me through it?
    > >
    > > Since I'm only gjournal'ing a portion of the underlying gmirror
    > > device I assume that I don't get this benefit?
    > >[...]

    > [...]
    > I decided to journal /usr /var /tmp and leave / as a standard UFS
    > partition because it is so small, fsck doesn't take long anyway and
    > hopefully doesn't get written to enough to cause damage by an abrupt
    > reboot. Because I'm not journaling the root partition, I chose to
    > ignore the possibility of gjournal marking the mirror clean. Sudden
    > reboots don't happen enough on servers for me to care. And all my
    > servers got abruptly rebooted this sunday and they all came up fine
    > [...]


    So you're confirming my belief that setting up gjournal on a
    bsdlabel'ed partition of a gmirror does *not* provide the consistency
    guarantee and that I should leave autosynchronization enabled. Right?

    g.
    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


+ Reply to Thread