Should gmirrored gjournal provider have auto-synchronization?

Hywel Mallett hywel at hmallett.co.uk
Thu Oct 7 23:02:18 UTC 2010


On 7 Oct 2010, at 08:35, Carl <k0802647 at telus.net> wrote:

> Suppose I've used a pair of drives laid out with GPT partitions to create a mirror. Actually, this situation requires that individual partitions be mirrored instead of the whole drive. Then suppose one of these partitions is to be gjournaled, but with separate data and journal providers. The separate journal provider will be in another partition.
> 
> I believe I should gmirror the journal provider partition just as I did the data provider partition. Correct me if this is wrong.

I would gmirror the journal. If it "goes away" unexpectedly, that won't be good for gjournal. I assume it'll panic. 

> Then, should I be enabling or disabling auto-synchronization for the mirrored journal provider partition? It is clear to me that it should be disabled for the mirrored data provider partition because the journaling will ensure data consistency, but is the content of the journal provider itself guaranteed consistent under all circumstances?

That's an interesting question. I think you're correct that you should be able to disable auto-sync for the data slice, provided that gmirror returns a write as succeeded only when it has been written to both parts of the mirror. If not, then you could theoretically end up with a situation where data has only been written to one half of the mirror, but the write has been returned as successful, and gjournal won't re-write the data, which would leave you with an unsynchronized mirror. 
With gmirror, when you say "guaranteed consistent", you may need to qualify that more. gmirror guarantees that a collection of writes either happens in it's entirety, or not at all. If you have for example an msdosfs on top of this, there's no guarantee of consistency anyway. With ufs + softupdates, it should guarantee consistency anyway, but the journal allows certain operations to be shortcutted.


More information about the freebsd-fs mailing list