Date: Thu, 11 Aug 2016 13:02:35 +0200 From: Julien Cigar <julien@perdition.city> To: Borja Marcos <borjam@sarenet.es> Cc: freebsd-fs@freebsd.org, Jordan Hubbard <jkh@ixsystems.com> Subject: Re: HAST + ZFS + NFS + CARP Message-ID: <20160811110235.GN70364@mordor.lan> In-Reply-To: <20160811101539.GM70364@mordor.lan> References: <65906F84-CFFC-40E9-8236-56AFB6BE2DE1@ixsystems.com> <B48FB28E-30FA-477F-810E-DF4F575F5063@gmail.com> <61283600-A41A-4A8A-92F9-7FAFF54DD175@ixsystems.com> <20160704183643.GI41276@mordor.lan> <AE372BF0-02BE-4BF3-9073-A05DB4E7FE34@ixsystems.com> <20160704193131.GJ41276@mordor.lan> <E7D42341-D324-41C7-B03A-2420DA7A7952@sarenet.es> <20160811091016.GI70364@mordor.lan> <1AA52221-9B04-4CF6-97A3-D2C2B330B7F9@sarenet.es> <20160811101539.GM70364@mordor.lan>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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@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. [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJXrFtIAAoJELK7NxCiBCPAc60QAJc0Trdq5aR2+B56Nru38wDs w7EsfdJtaPYqVHfn3JtinY0ShblNyvCqTWC5Cbm3yW9sJjmKht+Q1AlOuaSQM39U GVhq7SP71tnh72tgLu7UFHoagLeyF/QadJcvyYKdIJRlYMjZv5lUMdWdid2hhncb fBGGnSdyyuh+7IrGnExpG71gwv56BBDM0012831ypqSxUf++h3OQwutytjYKx1OK NEmpHgh9erTMk/wd6fb0oRKNLIK3RGiRPQijWGvkzkuURCSLcSDXCQTdNn0UQVWr I2SLaNg8HRWnEx9Ch030p7qhtjCv9jBQIyU9Vcj16ePJmqgbVXcaHHmUnH9v8sXB bO64Wgrp++ofKsqBM6dGdbqTOQGv4uJLY25uyVK+CAGUEMzvxeWhkC4A/Kubh2Dq CqfaEVhQwfPKpP3iilXZow05sFLVprqBqP8nHHUSo+QacNyuTv8ZhCaQwZSXzuL8 GVzNvt2foZndzGJCCfd0L+LhFydaJjMpnz05BQSRxVpljLrI7QSL8Jm3xTM7a9GS T1VP4dFqHHYqWEo/cGNQUPYhVYiqUIVIVwlyrZCMMaInDqIgdZQZiGdV2pn1qXJN U75nBSsKCq7wjYg7pBf2JtzP6cYZkbSgFyimK9+vH/iLNhdfnZioNEsNreggzr5Y kAesIncY5bdr1ELwLia5 =ViF3 -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160811110235.GN70364>