From owner-freebsd-geom@FreeBSD.ORG Thu Mar 12 11:02:50 2015 Return-Path: Delivered-To: freebsd-geom@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 6042E713 for ; Thu, 12 Mar 2015 11:02:50 +0000 (UTC) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E944C74B for ; Thu, 12 Mar 2015 11:02:49 +0000 (UTC) Received: from [87.79.197.90] (helo=fabiankeil.de) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1YW0sz-0005uq-6J for freebsd-geom@freebsd.org; Thu, 12 Mar 2015 12:02:41 +0100 Date: Thu, 12 Mar 2015 12:02:40 +0100 From: Fabian Keil To: freebsd-geom@freebsd.org Subject: Re: RFC: Pass TRIM through GELI Message-ID: <7e0bacf0.308742dc@fabiankeil.de> In-Reply-To: <20150308000131.GP1742@over-yonder.net> References: <20150308000131.GP1742@over-yonder.net> Reply-To: freebsd-geom@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/6e20ukgblZR40Gx4QlS/MOi"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 11:02:50 -0000 --Sig_/6e20ukgblZR40Gx4QlS/MOi Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable "Matthew D. Fuller" wrote: > I've done a quick implementation of TRIM passthru support for GELI. Awesome, looks like my TODO list just got shorter. > Patch attached is against late Feb -CURRENT; however, a glance at svn > suggests this code hasn't changed much, so it's probably pretty > portable forward and back. It applies cleanly to a stable/10 tree > though I haven't tried compiling or using it there. >=20 > This has been lightly tested and seems to work fine. It adds a '-t' > flag to init and onetime to enable passthru on the new provider, and > '-t/-T' options to configure to en/disable on existing (but see caveat > below about metadata versions; as written, you can't use this on > existing partitions). >=20 > Since all we're doing is passing it through instead of denying it, I'd > expect "seems to work" to be pretty much the same as "does work"; the > requests go through, space clears up, and messing with a little ZFS on > top of it doesn't show up any data corruption. I tested it with ZFS below geli and the result was newfs hanging "unkillabl= e" after sending the first delete request (according to the patched gnop): fk@r500 ~ $sudo geli init -t /dev/zvol/tank/scratch/scratchvol.nop Enter new passphrase:=20 Reenter new passphrase:=20 Metadata backup can be found in /var/backups/zvol_tank_scratch_scratchvol.n= op.eli and can be restored with the following command: # geli restore /var/backups/zvol_tank_scratch_scratchvol.nop.eli /dev/zvol= /tank/scratch/scratchvol.nop fk@r500 ~ $sudo geli attach /dev/zvol/tank/scratch/scratchvol.nop Enter passphrase:=20 fk@r500 ~ $sudo newfs -E /dev/zvol/tank/scratch/scratchvol.nop.eli /dev/zvol/tank/scratch/scratchvol.nop.eli: 500.0MB (1023992 sectors) block = size 32768, fragment size 4096 using 4 cylinder groups of 125.00MB, 4000 blks, 16000 inodes. Erasing sectors [128...1023991] load: 0.26 cmd: newfs 1583 [gdelete] 104.74r 0.00u 0.01s 0% 2932k load: 0.20 cmd: newfs 1583 [gdelete] 206.48r 0.00u 0.01s 0% 2932k load: 0.23 cmd: newfs 1583 [gdelete] 1293.55r 0.00u 0.01s 0% 2932k [different terminal:] fk@r500 ~ $gnop list Geom name: zvol/tank/scratch/scratchvol.nop WroteBytes: 409852928 ReadBytes: 960000 Cmd2s: 0 Cmd1s: 0 Cmd0s: 0 Flushes: 2 Getattrs: 55 Deletes: 1 Writes: 3163 Reads: 207 Error: 5 WriteFailProb: 0 ReadFailProb: 0 Offset: 0 Providers: 1. Name: zvol/tank/scratch/scratchvol.nop Mediasize: 524288000 (500M) Sectorsize: 512 Mode: r1w1e1 Consumers: 1. Name: zvol/tank/scratch/scratchvol Mediasize: 524288000 (500M) Sectorsize: 512 Stripesize: 8192 Stripeoffset: 0 Mode: r1w1e1 fk@r500 ~ $sudo procstat -kk $(pgrep newfs) PID TID COMM TDNAME KSTACK = =20 1583 100072 newfs - mi_switch+0xde sleepq_wait+0= x3a _sleep+0x2c5 biowait+0xa0 g_delete_data+0x63 g_dev_ioctl+0x176 devfs_io= ctl_f+0x13b kern_ioctl+0x401 sys_ioctl+0x153 amd64_syscall+0x3e7 Xfast_sysc= all+0xfb=20 The gnop statistic above includes a previous test without geli init -t. > In this implementation, I added a new G_ELI_VERSION and required it > for setting the flag. I actually think this is probably not > necessary; all we do is set a value in the flags field, and if it's > loaded onto a system that doesn't know what to do with that value, > it'll just do nothing, which IMO is fine. And since there is no `geli > upgrade`, this means that you can't enable it on any existing > partitions, but have to kill/init from scratch, which isn't very > user-friendly. So I propose that it actually be done sans those > version changes, but they are in the patch as attached for now. I agree that a version bump doesn't seem necessary. Fabian --Sig_/6e20ukgblZR40Gx4QlS/MOi Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUBck0ACgkQBYqIVf93VJ0icwCdHzy2SGR44fQ3z9OJ2hQwo5ti oIEAn3qiu82aIfsAsynIO8U5jxyJlRjh =pv8p -----END PGP SIGNATURE----- --Sig_/6e20ukgblZR40Gx4QlS/MOi--