HAST + ZFS + NFS + CARP

[Julien Cigar]

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,

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.
-------------- 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/11d79a93/attachment.sig>