RFC: Pass TRIM through GELI

[Fabian Keil]

"Matthew D. Fuller" <fullermd at over-yonder.net> 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.
> 
> 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).
> 
> 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 "unkillable"
after sending the first delete request (according to the patched gnop):

fk at r500 ~ $sudo geli init -t /dev/zvol/tank/scratch/scratchvol.nop
Enter new passphrase: 
Reenter new passphrase: 

Metadata backup can be found in /var/backups/zvol_tank_scratch_scratchvol.nop.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 at r500 ~ $sudo geli attach /dev/zvol/tank/scratch/scratchvol.nop
Enter passphrase: 
fk at 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 at 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 at r500 ~ $sudo procstat -kk $(pgrep newfs)
  PID    TID COMM             TDNAME           KSTACK                       
 1583 100072 newfs            -                mi_switch+0xde sleepq_wait+0x3a _sleep+0x2c5 biowait+0xa0 g_delete_data+0x63 g_dev_ioctl+0x176 devfs_ioctl_f+0x13b kern_ioctl+0x401 sys_ioctl+0x153 amd64_syscall+0x3e7 Xfast_syscall+0xfb 

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20150312/27dbb15d/attachment.sig>