From nobody Sun Aug 22 23:48:13 2021 X-Original-To: freebsd-fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D8AE7178E056 for ; Sun, 22 Aug 2021 23:48:31 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GtBsC4pvmz4tlN for ; Sun, 22 Aug 2021 23:48:31 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f41.google.com with SMTP id g66-20020a9d12c8000000b0051aeba607f1so23165962otg.11 for ; Sun, 22 Aug 2021 16:48:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bAr1argM5+pirInC5YXDXAMa2cimPSYBhy2mnwQj0fU=; b=mTnQQUeAQ3aaJpkP/yFlVqxh/TEaWqDV1wxLgQgDxdO6DlsrtN2V+8JW+MxAYN7+/b YtPq+mHh2jVSj4dFql+CDnwgEESVPhvFQWSRz98XxjBbwctgmivi9FXroEX9Cd2txvD3 t8EysHaoiO9YikALg+jUcArPmaT+H8h7TKvK7YFwNayk53gJ486d3JNUzP3BybiR5Aj1 IbyhBcIgc4P10itKO2ihf6EIrE4vwCJ9XDA4jip90sjwqbJbVaBT2mZ98B4UYz9xzh6+ fH2GBD/0Sni4T+vCTSy2Ddqj2WTDwnPU4j2SILzo//zEojE6mWyHJzfypzWVGl25i079 4rDw== X-Gm-Message-State: AOAM531F2VNHCWRw+EaxdKnHTj7REATOoyMBdSZI+DyWHwzybIYTX40B 9zYFVs9h2EmTPqU6iLDkGqj6tc/uuaFHyJWqIRywLH2e X-Google-Smtp-Source: ABdhPJxBAMZqXzUwlu+HMaGpXiaxICV4lpesUo2WFavvqhQqY/XTgkPkTkRNFMBMjqWqzyZ4HAgB+j8gbg9L85GB8Kw= X-Received: by 2002:a9d:d04:: with SMTP id 4mr26445297oti.251.1629676104826; Sun, 22 Aug 2021 16:48:24 -0700 (PDT) List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 References: <023225AD-2A97-47C5-9FE4-3ABF1BFD66F1@gmx.com> In-Reply-To: From: Alan Somers Date: Sun, 22 Aug 2021 17:48:13 -0600 Message-ID: Subject: Re: ZFS on high-latency devices To: George Michaelson Cc: Ben RUBSON , freebsd-fs Content-Type: multipart/alternative; boundary="00000000000053c29c05ca2e8922" X-Rspamd-Queue-Id: 4GtBsC4pvmz4tlN X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000053c29c05ca2e8922 Content-Type: text/plain; charset="UTF-8" mbuffer is not going to help the OP. He's trying to create a pool on top of a networked block device. And if I understand correctly, he's connecting over a WAN, not a LAN. ZFS will never achieve decent performance in such a setup. It's designed as a local file system, and assumes it can quickly read metadata off of the disks at any time. The OP's best option is to go with "a": encrypt each dataset and send them with "zfs send --raw". I don't know why he thinks that it would be "very difficult". It's quite easy, if he doesn't care about old snapshots. Just: $ zfs create pool/new_dataset $ cp -a pool/old_dataset/* pool/new_dataset/ -Alan On Sun, Aug 22, 2021 at 5:40 PM George Michaelson wrote: > I don't want to abuse the subject line too much, but I can highly > recommend the mbuffer approach, I've used this repeatedly, BSD-BSD and > BSD-Linux. It definitely feels faster than SSH, since the 'no cipher' > options were removed, and in the confusion of the HPC buffer changes. > But, its not crypted on-the-wire. > > Mbuffer tuning is a bit of a black art: it would help enormously if > there was some guidance on this, and personally I've never found the > mbuffer -v option to work well: I get no real sense of how full or > empty the buffer "is" or, if the use of sendmsg/recvmsg type buffer > chains is better or worse. > > -G > > On Fri, Aug 20, 2021 at 6:19 PM Ben RUBSON wrote: > > > > > On 19 Aug 2021, at 11:37, Peter Jeremy wrote: > > > > > > (...) or a way to improve throughput doing "zfs recv" to a pool with a > high RTT. > > > > You should use zfs send/receive through mbuffer, which will allow to > sustain better throughput over high latency links. > > Feel free to play with its buffer size parameters to find the better > settings, depending on your link characteristics. > > > > Ben > > > > > > --00000000000053c29c05ca2e8922--