RFC: Pass TRIM through GELI

[Pawel Jakub Dawidek]

On Tue, Jul 14, 2015 at 01:42:12AM -0500, Matthew D. Fuller wrote:
> On Mon, Jul 13, 2015 at 05:31:46PM +0200 I heard the voice of
> Pawel Jakub Dawidek, and lo! it spake thus:
> > 
> > So what do you guys think about implementing trim support this way:
> > 
> > 	geli -d <trim|overwrite|ignore>
> > 
> > 'overwrite' may be implemented later and 'trim' would be the default?
> 
> Well, if you ask me, we can work out the UI for a 3-way choice when a
> third way is implemented.  Doing shredding would presumably be noted
> by adding another flag[0] for it anyway, so doing it on top of this
> patch oughtn't take it out of its way.  Nobody's implemented it in the
> last 10 years that there's been a comment suggesting it.
> 
> So, from my selfish perspective, I'd as soon land this as a solid step
> forward, and worry about a shredding implementation when one gets
> written...
> 
> 
> [0] I mean, I _guess_ we could add another element into the
>     metadata/softc structs just to hold a 3-way 'delete handling'
>     option, but that sounds way heavier-weight than necessary.  Also
>     would need new geli version and blah.

I wanted to avoid changing command line arguments in the future for
people who automate GELI creation, but you know what, I just realized
that TRIM/UNMAP and overwrite are not mutually exclusive. I may want to
overwrite first and then do the TRIM. If those two are not mutually
exclusive then, finally, I think your patch is fine! Thank you for your
patience and expect the commit soon:)

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://mobter.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20150714/5a54754d/attachment.bin>