Date: Mon, 4 Jul 2016 15:03:30 +0200 (CEST) From: InterNetX - Juergen Gotteswinter <jg@internetx.com> To: Miroslav Lachman <000.fbsd@quip.cz>, Ben RUBSON <ben.rubson@gmail.com>, Julien Cigar <julien@perdition.city> Cc: freebsd-fs@freebsd.org Subject: Re: HAST + ZFS + NFS + CARP Message-ID: <1740049005.1349.a66cb17f-9141-4bef-b758-5bb129d16681.open-xchange@ox.internetx.com> In-Reply-To: <577A5CE3.8060100@quip.cz> References: <20160630144546.GB99997@mordor.lan> <71b8da1e-acb2-9d4e-5d11-20695aa5274a@internetx.com> <AD42D8FD-D07B-454E-B79D-028C1EC57381@gmail.com> <20160630153747.GB5695@mordor.lan> <63C07474-BDD5-42AA-BF4A-85A0E04D3CC2@gmail.com> <678321AB-A9F7-4890-A8C7-E20DFDC69137@gmail.com> <20160630185701.GD5695@mordor.lan> <6035AB85-8E62-4F0A-9FA8-125B31A7A387@gmail.com> <20160704122527.GH41276@mordor.lan> <577A5CE3.8060100@quip.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
i see so much pain upcoming when $something goes wrong, even the smallest piece will end up in drama zfs has been designed as a pragmatic stupid simpel solid solution, why whould one rape this concept with such complexity :( > Miroslav Lachman <000.fbsd@quip.cz> hat am 4. Juli 2016 um 14:56 geschrieben: > > > Julien Cigar wrote on 07/04/2016 14:25: > > > another option I had in mind is to export ZVOL through iSCSI: > > - on serverA: $> zpool create storage mirror /dev/ada1 /dev/ada2 > > - on serverB: $> zpool create storage mirror /dev/ada1 /dev/ada2 > > > > create a 50G dedicated redundant storage for serverC: > > - on serverA: $> zfs create -V 50G storage/serverc > > - on serverB: $> zfs create -V 50G storage/serverc > > > > iSCSI export /dev/zvol/storage/serverc from serverA and serverB and > > create a ZFS dataset on serverC: > > - on serverC: $> zpool create storage mirror /dev/ivol1 /dev/ivol2 > > > > (where ivol1 is the volume from serverA and ivol2 the volume from > > serverB) > > > > create, for example, a dataset for the dovecot service > > - on serverC: $> zfs create -o compress=lz4 storage/dovecot > > I think it will be painfully slow. ZFS on top of ZFS throught iSCSI... > too much layering, too much delays. > > Miroslav Lachman > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@freebsd.org Mon Jul 4 17:55:42 2016 Return-Path: <owner-freebsd-fs@freebsd.org> Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5CDE0B91222 for <freebsd-fs@mailman.ysv.freebsd.org>; Mon, 4 Jul 2016 17:55:42 +0000 (UTC) (envelope-from jkh@ixsystems.com) Received: from barracuda.ixsystems.com (barracuda.ixsystems.com [12.229.62.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 307762BC7 for <freebsd-fs@freebsd.org>; Mon, 4 Jul 2016 17:55:42 +0000 (UTC) (envelope-from jkh@ixsystems.com) X-ASG-Debug-ID: 1467654941-08ca0410fe51b40001-3nHGF7 Received: from zimbra.ixsystems.com ([10.246.0.20]) by barracuda.ixsystems.com with ESMTP id gdXKAcl8qjjLkiLM (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 04 Jul 2016 10:55:41 -0700 (PDT) X-Barracuda-Envelope-From: jkh@ixsystems.com X-Barracuda-RBL-Trusted-Forwarder: 10.246.0.20 X-ASG-Whitelist: Client Received: from localhost (localhost [127.0.0.1]) by zimbra.ixsystems.com (Postfix) with ESMTP id 8B29FCA4024; Mon, 4 Jul 2016 10:55:41 -0700 (PDT) Received: from zimbra.ixsystems.com ([127.0.0.1]) by localhost (zimbra.ixsystems.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 5Ra626h0xOLI; Mon, 4 Jul 2016 10:55:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.ixsystems.com (Postfix) with ESMTP id 2DA1FCA414F; Mon, 4 Jul 2016 10:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at ixsystems.com Received: from zimbra.ixsystems.com ([127.0.0.1]) by localhost (zimbra.ixsystems.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NAscgVdF_ydd; Mon, 4 Jul 2016 10:55:41 -0700 (PDT) Received: from [172.20.0.34] (vpn.ixsystems.com [10.249.0.2]) by zimbra.ixsystems.com (Postfix) with ESMTPSA id DD06DCA4024; Mon, 4 Jul 2016 10:55:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: HAST + ZFS + NFS + CARP From: Jordan Hubbard <jkh@ixsystems.com> X-ASG-Orig-Subj: Re: HAST + ZFS + NFS + CARP In-Reply-To: <B48FB28E-30FA-477F-810E-DF4F575F5063@gmail.com> Date: Mon, 4 Jul 2016 10:55:40 -0700 Cc: freebsd-fs@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <61283600-A41A-4A8A-92F9-7FAFF54DD175@ixsystems.com> References: <20160630144546.GB99997@mordor.lan> <71b8da1e-acb2-9d4e-5d11-20695aa5274a@internetx.com> <AD42D8FD-D07B-454E-B79D-028C1EC57381@gmail.com> <20160630153747.GB5695@mordor.lan> <63C07474-BDD5-42AA-BF4A-85A0E04D3CC2@gmail.com> <678321AB-A9F7-4890-A8C7-E20DFDC69137@gmail.com> <20160630185701.GD5695@mordor.lan> <6035AB85-8E62-4F0A-9FA8-125B31A7A387@gmail.com> <20160703192945.GE41276@mordor.lan> <20160703214723.GF41276@mordor.lan> <65906F84-CFFC-40E9-8236-56AFB6BE2DE1@ixsystems.com> <B48FB28E-30FA-477F-810E-DF4F575F5063@gmail.com> To: Ben RUBSON <ben.rubson@gmail.com> X-Mailer: Apple Mail (2.3124) X-Barracuda-Connect: UNKNOWN[10.246.0.20] X-Barracuda-Start-Time: 1467654941 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://10.246.0.26:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ixsystems.com X-Barracuda-BRTS-Status: 1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems <freebsd-fs.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-fs>, <mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs/>; List-Post: <mailto:freebsd-fs@freebsd.org> List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-fs>, <mailto:freebsd-fs-request@freebsd.org?subject=subscribe> X-List-Received-Date: Mon, 04 Jul 2016 17:55:42 -0000 > On Jul 3, 2016, at 11:05 PM, Ben RUBSON <ben.rubson@gmail.com> wrote: >=20 > Of course Jordan, in this topic, we (well at least me :) make the = following assumption : > one iSCSI target/disk =3D one real physical disk (a SAS disk, a SSD = disk...), from a server having its own JBOD, no RAID adapter or = whatever, just what ZFS likes ! I certainly wouldn=E2=80=99t make that assumption. Once you allow iSCSI = to be the back-end in any solution, end-users will avail themselves of = the flexibility to also export arbitrary or synthetic devices (like = zvols / RAID devices) as =E2=80=9Cdisks=E2=80=9D. You can=E2=80=99t = stop them from doing so, so you might as well incorporate that scenario = into your design. Even if you could somehow enforce the 1:1 mapping of = LUN to disk, iSCSI itself is still going to impose a serialization / = performance / reporting (iSCSI LUNs don=E2=80=99t report SMART status) = penalty that removes a lot of the advantages of having direct physical = access to the media, so one might also ask what you=E2=80=99re gaining = by imposing those restrictions. - Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1740049005.1349.a66cb17f-9141-4bef-b758-5bb129d16681.open-xchange>