From nobody Mon Aug 23 17:54:41 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 8BD1A1774719
	for <freebsd-fs@mlmmj.nyi.freebsd.org>; Mon, 23 Aug 2021 17:54:45 +0000 (UTC)
	(envelope-from lev@FreeBSD.org)
Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (4096 bits) client-digest SHA256)
	(Client CN "smtp.freebsd.org", Issuer "R3" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4GtfyY3ZH5z4dsp;
	Mon, 23 Aug 2021 17:54:45 +0000 (UTC)
	(envelope-from lev@FreeBSD.org)
Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	(Authenticated sender: lev/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4859CF2C0;
	Mon, 23 Aug 2021 17:54:45 +0000 (UTC)
	(envelope-from lev@FreeBSD.org)
Received: from [192.168.134.16] (unknown [94.19.243.255])
	(Authenticated sender: lev@serebryakov.spb.ru)
	by onlyone.not-for.work (Postfix) with ESMTPSA id 932F8ECD1;
	Mon, 23 Aug 2021 20:54:41 +0300 (MSK)
Reply-To: lev@FreeBSD.org
Subject: Re: ZFS on high-latency devices
To: Alan Somers <asomers@freebsd.org>, George Michaelson <ggm@algebras.org>
Cc: Ben RUBSON <ben.rubson@gmx.com>, freebsd-fs <freebsd-fs@freebsd.org>
References: <YR4mY+b6o7fBJqEN@server.rulingia.com>
 <023225AD-2A97-47C5-9FE4-3ABF1BFD66F1@gmx.com>
 <CAKr6gn0r8xG9HNGOFh1A_usU4tPAYezeZv1chOG_bBMqy_HtXw@mail.gmail.com>
 <CAOtMX2hRuh_9ZOOoQufNT2QG3Ui0S3rJq+L-ox2kxsq1oJMSMA@mail.gmail.com>
From: Lev Serebryakov <lev@FreeBSD.org>
Organization: FreeBSD
Message-ID: <90ec9734-c4d8-b164-aec1-f95fcfda913b@FreeBSD.org>
Date: Mon, 23 Aug 2021 20:54:41 +0300
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.13.0
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-fs
List-Help: <mailto:freebsd-fs+help@freebsd.org>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Subscribe: <mailto:freebsd-fs+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-fs+unsubscribe@freebsd.org>
Sender: owner-freebsd-fs@freebsd.org
MIME-Version: 1.0
In-Reply-To: <CAOtMX2hRuh_9ZOOoQufNT2QG3Ui0S3rJq+L-ox2kxsq1oJMSMA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-ThisMailContainsUnwantedMimeParts: N

On 23.08.2021 2:48, Alan Somers wrote:

> 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 <crypto options> pool/new_dataset
> $ cp -a pool/old_dataset/* pool/new_dataset/

  Twice the space? And, realistically, triple the space to have enough free space before destroying pool/old_dataset, as ZFS feels bad on near-full pools.

  Sometimes it is "just", sometimes it is impossible!

-- 
// Lev Serebryakov