From owner-freebsd-fs@FreeBSD.ORG Fri Feb 20 10:20:03 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5073EB4F for ; Fri, 20 Feb 2015 10:20:03 +0000 (UTC) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (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 1E70E252 for ; Fri, 20 Feb 2015 10:20:03 +0000 (UTC) Received: by iecar1 with SMTP id ar1so6811154iec.0 for ; Fri, 20 Feb 2015 02:20:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=Sijqlx2y8SN4IAxL2UquJQmpI4nxGomZiLHot0Tg5lQ=; b=0t2rL8HQvBt+2AJ6h0KmmzzehXaZfdTed0l+nTQcyIXszeDI71wXTpkXpqXpeNRaux OEd1JaV9YHimtVy1I5BY6wf3fV6c5+1BWpDBYPyM9bLFo0fZjoHQ3mWQ7sLpnkJCO+zU GO23kbJ5ywunw+ujVtWfK1oQx55+2ckI9ccr55gENuDfp3svIgv14BV6gjCOL9S9ZRD+ J89i2oIsMFuDUnfBXBBuuR1X+PGCFmBWGx0Ez5cSbry/s0w0hUb/CSyofjIl9YCwsocY VhRy9gmujD3/DdUTi9inAmNSv/TyX/3+qlFzKyi5Rp8gFmLvn1BFfYwi0cq3aRPRb9Tv +Msg== MIME-Version: 1.0 X-Received: by 10.107.15.96 with SMTP id x93mr8466613ioi.75.1424427602267; Fri, 20 Feb 2015 02:20:02 -0800 (PST) Received: by 10.107.14.199 with HTTP; Fri, 20 Feb 2015 02:20:02 -0800 (PST) In-Reply-To: <54E63D17.4000006@delphij.net> References: <54E5BB12.3060707@fuckner.net> <54E5CF6E.5030906@multiplay.co.uk> <54E5D574.8020406@fuckner.net> <54E5F19A.3080804@kateley.com> <54E61C18.8070101@fuckner.net> <54E63D17.4000006@delphij.net> Date: Fri, 20 Feb 2015 10:20:02 +0000 Message-ID: Subject: Re: Creating zpool on NVMe Disks takes forever From: Tom Evans Cc: FreeBSD FS Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 10:20:03 -0000 On Thu, Feb 19, 2015 at 1:33 PM, Steven Hartland wrote: > Technically is not TRIM / UNMAP its BIO_DELETE which is translated by the > relevant device driver to the format the device understands. > > For SCSI this can be TRIM, UNMAP, WS or ZERO, for ATA this can be CFA_ERASE > or TRIM and for NVMe this is a Deallocate. > > One reason why it might be slow is I don't see NVMe configuring geom > d_delmaxsize, which if the case will force the "TRIM" to be split into > single sector deallocation requests. So "zfs_trim_on_init" doesn't require TRIM, it simply ensures it has wiped all data regardless of what the device supports. On Thu, Feb 19, 2015 at 7:44 PM, Xin Li wrote: > Encrypted GEOM providers does not support TRIM (neither pass-through > nor random initialization) right now, so this doesn't matter, at least > not yet. Given the above, doesn't this mean that encrypted geoms will be erased block by block on init, regardless of whether they can TRIM or not. Cheers Tom