From owner-freebsd-fs@FreeBSD.ORG Fri Feb 20 10:28:38 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE00CDC1 for ; Fri, 20 Feb 2015 10:28:38 +0000 (UTC) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (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 4FE79358 for ; Fri, 20 Feb 2015 10:28:37 +0000 (UTC) Received: by wesw62 with SMTP id w62so4719523wes.9 for ; Fri, 20 Feb 2015 02:28:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VYtLp+ER/2Mefyyl/iy2fho5nK1gDuPTsENhbZjRJZY=; b=XnqlAdfZ2yWIiwE3/s09Lwg5i4c6BJgUB9Fih+cvyXWPuQ1GbzXvXpIrPes4y+1yIL xPPHVeqRktMMVDYSQlPVEB7fQDTR8V+jcV0NqwcP26PwAsMo30i/EMD6P+90JCtLWy5W dC7x+xtko94VVXK5DKAnpfyNKkrGmDu/GikS0TvW8ao+Dt1ZZjmvTYUHohx/moL0cz0P goPxN4FxZNX7e7nZvnroq269KgCA90kV5ozcsbziRdQqi6JX+ma+6jHkUO8VDBMezOaM t4OCjuFkzEXZW+UYX9QyfNwBQOe68zGIJVB/7FmNldspwFJ50rcwCNVe49oxbHDCUHhN VwbA== X-Gm-Message-State: ALoCoQkpwDQwNOZPC5NsiBiVv/Dm+yVcmV7z09JVIJonDyUCQB29q43UoHZhMdkXTRLf5jXJLsg+ X-Received: by 10.194.185.9 with SMTP id ey9mr17426218wjc.135.1424428109017; Fri, 20 Feb 2015 02:28:29 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id fo9sm1720462wib.16.2015.02.20.02.28.26 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Feb 2015 02:28:28 -0800 (PST) Message-ID: <54E70C49.80501@multiplay.co.uk> Date: Fri, 20 Feb 2015 10:28:25 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: Creating zpool on NVMe Disks takes forever 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> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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:28:38 -0000 On 20/02/2015 10:20, Tom Evans wrote: > 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. No it will process deletes if the underlying device supports it, not all do. > 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. > Nope, last time I looked GELI it didn't support DELETE at all, so the requests would be ignored. Regards Steve