From owner-freebsd-current@freebsd.org Mon Oct 3 09:35:18 2016 Return-Path: Delivered-To: freebsd-current@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 5B6C8AC647C for ; Mon, 3 Oct 2016 09:35:18 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 D75A8C62; Mon, 3 Oct 2016 09:35:17 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bs.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1bqzeO-0003Wp-Vx; Mon, 03 Oct 2016 12:35:09 +0300 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: ZFS - Abyssal slow on copying From: Daniel Braniss In-Reply-To: <20161003113050.0f1b09bd.ohartman@zedat.fu-berlin.de> Date: Mon, 3 Oct 2016 12:35:08 +0300 Cc: Allan Jude , freebsd-current@freebsd.org Message-Id: <28DF6F19-A97F-4029-9D55-77E14B38B45D@cs.huji.ac.il> References: <20161002212504.2d782002.ohartman@zedat.fu-berlin.de> <20161003113050.0f1b09bd.ohartman@zedat.fu-berlin.de> To: "O. Hartmann" X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 09:35:18 -0000 > On 3 Oct 2016, at 12:30 PM, O. Hartmann = wrote: >=20 > Am Sun, 2 Oct 2016 15:30:41 -0400 > Allan Jude > = schrieb: >=20 >> On 2016-10-02 15:25, O. Hartmann wrote: >>>=20 >>> Running 12-CURRENT (FreeBSD 12.0-CURRENT #32 r306579: Sun Oct 2 = 09:34:50 CEST 2016 >>> ), I have a NanoBSD setup which creates an image for a router = device. >>>=20 >>> The problem I face is related to ZFS. The system has a system's SSD = (Samsung 850 Pro, >>> 256GB) which has an UFS filesystem. Aditionally, I have also a = backup and a data HDD, >>> both WD, one 3 TB WD RED Pro, on 4 TB WD RED (the backup device). = Both the sources for >>> the NanoBSD and the object tree as well as the NANO_WORLDDIR are = residing on the 3 TB >>> data drive.=20 >>>=20 >>> The box itself has 8 GB RAM. When it comes to create the memory = disk, which is ~ 1,3 >>> GB in size, the NanoBSD script starts creating the memory disk and = then installing >>> world into this memory disk. And this part is a kind of abyssal in = terms of the speed. >>>=20 >>> The drive sounds like hell, the heads are moving rapidly. The copy = speed is incredibly >>> slow compared to another box I usually use in the lab with UFS = filesystem only >>> (different type of HDD). >>>=20 >>> The whole stuff the nanbsd is installed from and to is on a separate = ZFS partition, >>> but in the same pool as everything else. When I first setup the new = partitions, I >>> switched on deduplication, but I quickly deactivated it, because it = had a tremendous >>> impact on the working speed and memory consumption on that box. But = something seems >>> not right since then - as I initially described, the = copy/initialisation >>> speed/bandwith is abyssal. Well, I also fear that I did something = wrong when I firt >>> initialised the HDD - there is this 125bytes/4k block discussion and = I do not know >>> how to check whether I'm affected to that or not (or even causing = the problems) and >>> how to check whether DEDUPLICATION is definitely OFF (apart from the = usual stuff list >>> features via "zfs get all"). >>>=20 >>> As an example: the nanbosd script takes ~ 1 minute to copy = /boot/loader from source to >>> memory disk and the HDD makes sounds like hell and close to loosing = the r/w heads. On >>> other boxes this task is done in a blink of an eye ... >>>=20 >>> Thanks for your patience, >>>=20 >>> Regards, >>> oh >>>=20 >>=20 >> Turning deduplication off, only stops new blocks from being >> deduplicated. Any data written while deduplication was on, are still >> deduplicated. You would need to zfs send | zfs recv, or >> backup/destroy/restore to get the data back to normal. >>=20 >> If the drive is making that much noise, have you considered that the >> drive might be failing? >>=20 >=20 > Hello. >=20 > Might there be any hint I can investigate on that ZFS partition = showing me that the > particular partition is still doing deduplication? If I wouldn't know = that I switch > dedup on and later off, I would blame the OS instead. So, for further = forensik analysis > in the future, it would be nice to know how to look at it - if it is = doable via simple > checking the features of the ZFS partition ... >=20 > Thanks, > oh=20 not really an answer, but zpool has a nice command: history, it = sometimes helps to find what and when nfs commands where given. =20 danny