From owner-freebsd-fs@freebsd.org Mon Jul 4 06:05:44 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 B72EBB91FC1 for ; Mon, 4 Jul 2016 06:05:44 +0000 (UTC) (envelope-from ben.rubson@gmail.com) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48E1A2189 for ; Mon, 4 Jul 2016 06:05:44 +0000 (UTC) (envelope-from ben.rubson@gmail.com) Received: by mail-wm0-x230.google.com with SMTP id 187so19509991wmz.1 for ; Sun, 03 Jul 2016 23:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=QItGqZLKOiOpEjOND7ggoU7vUSG9BeckU2CR6iaoWVk=; b=MaZ7XppwPD1DG3ANKm5B7329UbwSS0DNU7ynBNx1F1InJ3Y7cqwppPHbQH25V3hzBk /Mm3c3YU5IwbCm2rn4wJfpq55J7xOfV7StTVv/SuEaPHMLCehM7g7YDsP9CqF2SZg+jN 0IXkm78jRndwBOUwbVsNeyUXyPNhmIppSRdm/y9WBTZFyi0FthjiK5pXZ5YMYqyAlODD bOSF66RPHPkOSbWNy4aIgYTvzIPAgrKHG87KhadTIxxLTl6AgVa9jrIibj47p7se3Cnb cKYzb3tSNYiznhOgCDrkHWJ7iNPi2RXfys636fJ0jl5I0y3x9LTT8VTBy9TI9pgwm0BX mOIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=QItGqZLKOiOpEjOND7ggoU7vUSG9BeckU2CR6iaoWVk=; b=Iuebc303HB9a4RHZZMDCGRNQmV8scrTd67KxZVm362t12Fq+QmlzHrDaxZ7/YzzgtE HPciRmbsB/ttVE3Wn3ytRfJFDFgFIC9s5g/Qsb7I31uqQs7PaJsTd9w3NfIedY9DgEFD PCjXxYDnz5S7NRxGPqhVeaFcYnKdnM/VjgephH36wVcVKuiPuPzLsfGtiJyTUl/swfPV m1e4S8bmAQaeeyYPxB2UztNf2eGsBCd8VTJB5jY3n8gvTk7K0hYsfzTOK0aPuSjP1yr5 1C8rhx8r3n5rOPXkntODR2Md/7cogQCQfLkOSiJzmG9OIHLOyrz1WQVQRLIi03G/k2PH ZA4w== X-Gm-Message-State: ALyK8tKU7KVZVLvccgy2+dZrT/zZupP4+3KkpUpPrtw3Dyh2T+HEwfRCM0TDhCyzKmyRxQ== X-Received: by 10.28.158.206 with SMTP id h197mr9322348wme.50.1467612342320; Sun, 03 Jul 2016 23:05:42 -0700 (PDT) Received: from macbook-air-de-benjamin-1.home (LFbn-1-7077-85.w90-116.abo.wanadoo.fr. [90.116.246.85]) by smtp.gmail.com with ESMTPSA id w15sm2306056wmd.11.2016.07.03.23.05.41 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 03 Jul 2016 23:05:41 -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: Ben RUBSON In-Reply-To: <65906F84-CFFC-40E9-8236-56AFB6BE2DE1@ixsystems.com> Date: Mon, 4 Jul 2016 08:05:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: 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: freebsd-fs@freebsd.org X-Mailer: Apple Mail (2.3124) 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 06:05:44 -0000 > On 04 Jul 2016, at 00:24, Jordan Hubbard wrote: >=20 >> On Jul 3, 2016, at 2:47 PM, Julien Cigar = wrote: >>=20 >> I guess that ZFS will split the read requests accross all devices in >> order to maximize performance... which could lead to contrary to what = is >> expecpted when iSCSI disks are involved, no? >> Is there some sysctl params which could prevent this unexpected >> behavior? >=20 > Nope. You will suffer the performance implications of layering a = filesystem that expects =E2=80=9Crotating media or SSDs=E2=80=9D (with = the innate ability to parallelize multiple requests in a way that ADD = performance) on top of a system which is now serializing the requests = across an internet connection to another software layer which may offer = no performance benefits to having multiple LUNs at all. You can try = iSCSI-specific tricks like MPIO to try and increase performance, but ZFS = itself is just going to treat everything it sees as =E2=80=9Ca disk=E2=80=9D= and so physical concepts like mirrors or multiple vdevs for performance = won=E2=80=99t translate across. >=20 > Example question: What=E2=80=99s the point of writing multiple copies = of data across virtual disks in a mirror configuration if the underlying = storage for the virtual disks is already redundant and the I/Os to it = serialize? > Example Answer: There is no point. In fact, it=E2=80=99s a = pessimization to do so. 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 ! > This is not a lot different than running ZFS on top of RAID = controllers that turn N physical disks into 1 or more virtual disks. = You have to make entirely different performance decisions based on such = scenarios and that=E2=80=99s just the way it is, which is also why we = don=E2=80=99t recommend doing that. Of course you loose all ZFS benefits if you only mirror 2 "disks", a big = one from storage array A, the same from storage array B. No interest.