Date: Sun, 22 Jun 2008 19:58:34 +0200 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-geom@freebsd.org Subject: Re: Filesystem replication geom proposal Message-ID: <g3m3se$eau$1@ger.gmane.org> In-Reply-To: <0A8C1986-1DC1-4445-9111-0DEDBBCC6847@hmallett.co.uk> References: <0A8C1986-1DC1-4445-9111-0DEDBBCC6847@hmallett.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1504CD62C27849ABF1105167 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hywel Mallett wrote: > FreeBSD doesn't have a defined method of replicating data between two=20 > servers, for HA/DR purposes, similar to Veritas Volume Replicator. Linu= x=20 > has DRDB (http://www.drbd.org/) which isn't quite the same, and someone= =20 > has tried using gmirror and ggate to have a mirror across teo systems, = > but neither of those can cope well with a disconnected network, or a=20 > slow network link. > I was wondering if there would be any interest in creating a new geom=20 > provider to solve this problem. I can see that questions about this=20 > functionality have been asked on the mailing lists before, and I've=20 > drawn up some initial thoughts aand ideas at=20 > http://www.hmallett.co.uk/computing-mainmenu-49/72-computing/124-open-s= ource-replicated-filesystems.html=20 Hmmm. If I understand your proposal, you want to create IO journals on=20 both the master and the slave, then replicate journal data from the=20 master to the slave, then replay the journal on the slave? This looks=20 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). The DCM looks like an alternative to the above "transactional" method of = replication - it looks like instead of asynchronously replaying the=20 transaction log, you constantly replicate the DCM to the slave (or at=20 least the changed bits), and then the slave asks the server to send the=20 blocks corresponding to what's marked as changed in the DCM, right? Regarding swapping the master/slave roles: I think you need a fsck step=20 somewhere in there, or the same tricks gjournal uses (hooks into UFS)=20 since the file system will be marked dirty if you suddenly stop using=20 it. Also, to manually force the failover, the master needs to umount the = file system, probably with "-f". Will it work? Of course, if you think the things you proposed will solve reliable=20 replication of data across the network, go ahead :) But since=20 ggate+gmirror has already tried to solve this, maybe you'd be interested = in increasing their reliability, as an exercise before trying something=20 from scratch? --------------enig1504CD62C27849ABF1105167 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIXpLKldnAQVacBcgRAkDWAKCVLdvBBvhXKnCu227t/Rzk9tg6FwCgphKI Kvu6ziF/NbwjFq7juqW/p1s= =5KG3 -----END PGP SIGNATURE----- --------------enig1504CD62C27849ABF1105167--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?g3m3se$eau$1>