RFC: Pass TRIM through GELI
John-Mark Gurney
jmg at funkthat.com
Fri Mar 13 02:50:35 UTC 2015
Matthew D. Fuller wrote this message on Sat, Mar 07, 2015 at 18:01 -0600:
> [ bcc'd to -fs because it's been discussed there in the past; followup
> to -geom because that seems where it belongs ]
>
> I've done a quick implementation of TRIM passthru support for GELI.
> 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.
>
> The patch to gnop in
> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198405> is a useful
> adjunct in checking when/if the requests actually go through, by
> making the .eli on top of the .nop and seeing when the counters tick.
>
>
> 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.
>
>
> One not-quite-related change in here is that I added a denial for
> 'geli configure' attempts on onetime providers. Trying this causes a
> panic, as the metadata version field on onetime providers is
> nonsensical. As far as I can tell in quick testing, this isn't
> related to my changes; it happens with stock GELI code as well.
> Presumably it's never been noticed before since the only prior use for
> 'geli configure' was to un/set the BOOT flag, which makes no sense on
> a onetime anyway, so nobody ever bothered trying. But with -[tT],
> somebody might try. Evidence: I did, and found the panic :)
Oh, it looks like we have a flag to show if a provider can delete,
see:
svnweb.freebsd.org/changeset/base/r279913
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
More information about the freebsd-geom
mailing list