HAST + ZFS + NFS + CARP

[Julien Cigar]

On Thu, Aug 11, 2016 at 12:15:39PM +0200, Julien Cigar wrote:
> On Thu, Aug 11, 2016 at 11:24:40AM +0200, Borja Marcos wrote:
> > 
> > > On 11 Aug 2016, at 11:10, Julien Cigar <julien at perdition.city> wrote:
> > > 
> > > As I said in a previous post I tested the zfs send/receive approach (with
> > > zrep) and it works (more or less) perfectly.. so I concur in all what you
> > > said, especially about off-site replicate and synchronous replication.
> > > 
> > > Out of curiosity I'm also testing a ZFS + iSCSI + CARP at the moment, 
> > > I'm in the early tests, haven't done any heavy writes yet, but ATM it 
> > > works as expected, I havent' managed to corrupt the zpool.
> > 
> > I must be too old school, but I don’t quite like the idea of using an essentially unreliable transport
> > (Ethernet) for low-level filesystem operations.
> > 
> > In case something went wrong, that approach could risk corrupting a pool. Although, frankly,

Now I'm thinking of the following scenario:
- filer1 is the MASTER, filer2 the BACKUP
- on filer1 a zpool data mirror over loc1, loc2, rem1, rem2 (where rem1 
and rem2 are iSCSI disks)
- the pool is mounted on MASTER

Now imagine that the replication interface corrupts packets silently,
but data are still written on rem1 and rem2. Does ZFS will detect 
immediately that written blocks on rem1 and rem2 are corrupted?

> 
> Yeah.. although you could have silent data corruption with any broken
> hardware too. Some years ago I suffered a silent data corruption due to 
> a broken RAID card, and had to restore from backups..
> 
> > ZFS is extremely resilient. One of mine even survived a SAS HBA problem that caused some
> > silent corruption.
> 
> Yep, and I would certainly not use another FS to do that. Scrubbing the
> pool more regularly is also something to do.
> 
> > 
> > The advantage of ZFS send/receive of datasets is, however, that you can consider it
> > essentially atomic. A transport corruption should not cause trouble (apart from a failed
> > "zfs receive") and with snapshot retention you can even roll back. You can’t roll back
> > zpool replications :)
> > 
> > ZFS receive does a lot of sanity checks as well. As long as your zfs receive doesn’t involve a rollback
> > to the latest snapshot, it won’t destroy anything by mistake. Just make sure that your replica datasets
> > aren’t mounted and zfs receive won’t complain.
> > 
> > 
> > Cheers,
> > 
> > 
> > 
> > 
> > Borja.
> > 
> > 
> > 
> 
> -- 
> Julien Cigar
> Belgian Biodiversity Platform (http://www.biodiversity.be)
> PGP fingerprint: EEF9 F697 4B68 D275 7B11  6A25 B2BB 3710 A204 23C0
> No trees were killed in the creation of this message.
> However, many electrons were terribly inconvenienced.



-- 
Julien Cigar
Belgian Biodiversity Platform (http://www.biodiversity.be)
PGP fingerprint: EEF9 F697 4B68 D275 7B11  6A25 B2BB 3710 A204 23C0
No trees were killed in the creation of this message.
However, many electrons were terribly inconvenienced.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20160811/741802d3/attachment.sig>