From owner-freebsd-fs@freebsd.org Mon Jul 4 13:03:45 2016 Return-Path: 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 8BE3BB917E5 for ; Mon, 4 Jul 2016 13:03:45 +0000 (UTC) (envelope-from jg@internetx.com) Received: from mx1.internetx.com (mx1.internetx.com [62.116.129.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1BAF02050 for ; Mon, 4 Jul 2016 13:03:44 +0000 (UTC) (envelope-from jg@internetx.com) Received: from localhost (localhost [127.0.0.1]) by mx1.internetx.com (Postfix) with ESMTP id D730045FC0EA; Mon, 4 Jul 2016 15:03:35 +0200 (CEST) X-Virus-Scanned: InterNetX GmbH amavisd-new at ix-mailer.internetx.de Received: from mx1.internetx.com ([62.116.129.39]) by localhost (ix-mailer.internetx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMeFDcp9n0mu; Mon, 4 Jul 2016 15:03:30 +0200 (CEST) Received: from ox-groupware-node01.internetx.de (ox.internetx.com [85.236.36.83]) by mx1.internetx.com (Postfix) with ESMTP id 3A82A45FC0E8; Mon, 4 Jul 2016 15:03:30 +0200 (CEST) Received: from ox-groupware-node01.internetx.de (localhost [127.0.0.1]) by ox-groupware-node01.internetx.de (Postfix) with ESMTP id 266E3A1213E; Mon, 4 Jul 2016 15:03:30 +0200 (CEST) Date: Mon, 4 Jul 2016 15:03:30 +0200 (CEST) From: InterNetX - Juergen Gotteswinter To: Miroslav Lachman <000.fbsd@quip.cz>, Ben RUBSON , Julien Cigar Cc: freebsd-fs@freebsd.org 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> <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> Subject: Re: HAST + ZFS + NFS + CARP MIME-Version: 1.0 X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.8.0-Rev27 Organization: InterNetX GmbH X-Originating-Client: com.openexchange.ox.gui.dhtml Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 13:03:45 -0000 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: 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 ; 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 ; 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 X-ASG-Orig-Subj: Re: HAST + ZFS + NFS + CARP In-Reply-To: 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> <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> To: Ben RUBSON 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 17:55:42 -0000 > On Jul 3, 2016, at 11:05 PM, Ben RUBSON 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