HAST + ZFS + NFS + CARP

Wed Aug 17 07:31:57 UTC 2016

Am 11.08.2016 um 11:24 schrieb Borja Marcos:
> 
>> 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,
> ZFS is extremely resilient. One of mine even survived a SAS HBA problem that caused some
> silent corruption.

try dual split import :D i mean, zpool -f import on 2 machines hooked up
to the same disk chassis.

kaboom, really ugly kaboom. thats what is very likely to happen sooner
or later especially when it comes to homegrown automatism solutions.
even the commercial parts where much more time/work goes into such
solutions fail in a regular manner

> 
> 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.
> 
> 
> 
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
> 