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
pgpixDMSm9VD7.pgp
Description: PGP signature
