Date: Sun, 22 Jun 2008 23:36:38 +0100 From: hywel@hmallett.co.uk To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-geom@freebsd.org Subject: Re: Filesystem replication geom proposal Message-ID: <20080622233638.4hclgmsw8408s4cg@www.hmallett.co.uk> In-Reply-To: <g3m3se$eau$1@ger.gmane.org> References: <0A8C1986-1DC1-4445-9111-0DEDBBCC6847@hmallett.co.uk> <g3m3se$eau$1@ger.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Ivan Voras <ivoras@freebsd.org>: > Hmmm. If I understand your proposal, you want to create IO journals on > both the master and the slave, then replicate journal data from the > master to the slave, then replay the journal on the slave? That's about the size of it. > This looks > like a lot of work for something that looks like it could be > implemented by a linked list in the kernel (to achieve aynchronous > operation). I don't know about that... > The DCM looks like an alternative to the above "transactional" method > of replication - it looks like instead of asynchronously replaying the > transaction log, you constantly replicate the DCM to the slave (or at > least the changed bits), and then the slave asks the server to send the > blocks corresponding to what's marked as changed in the DCM, right? The DCM only gets used during initial synchronisation, or when the =20 outstanding transactions have overflowed the log (which is a bad =20 thing), so the DCM gets little used, and only when the slave is =20 inconsistent. > Regarding swapping the master/slave roles: I think you need a fsck step > somewhere in there, or the same tricks gjournal uses (hooks into UFS) > since the file system will be marked dirty if you suddenly stop using > it. Also, to manually force the failover, the master needs to umount > the file system, probably with "-f". Will it work? I would agree with all that. I haven't looked into the UFS hooks used =20 by gjournal in any depth, so will investigate more. > Of course, if you think the things you proposed will solve reliable > replication of data across the network, go ahead :) But since > ggate+gmirror has already tried to solve this, maybe you'd be > interested in increasing their reliability, as an exercise before > trying something from scratch? I certainly agree that there's no point in reinventing the wheel, =20 however I don't see how gmirror, without major changes, can work in a =20 way that can cope with a disconnected network and maintain data =20 consistency when the network is reconnected. As a result of your comments I've added some more details to the =20 original article. --=20 Hywel Mallett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080622233638.4hclgmsw8408s4cg>