Date: Tue, 14 Jul 2015 01:42:12 -0500 From: "Matthew D. Fuller" <fullermd@over-yonder.net> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: RW <rwmaillists@googlemail.com>, freebsd-geom@freebsd.org Subject: Re: RFC: Pass TRIM through GELI Message-ID: <20150714064212.GZ96394@over-yonder.net> In-Reply-To: <20150713153146.GA1984@garage.freebsd.pl> References: <20150308000131.GP1742@over-yonder.net> <20150324021924.GQ52331@over-yonder.net> <20150502125220.GS78376@over-yonder.net> <20150629013841.GO50491@over-yonder.net> <20150710200055.GB1270@garage.freebsd.pl> <20150710222837.GE96394@over-yonder.net> <20150711141553.3fcf91f4@gumby.homeunix.com> <20150713153146.GA1984@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
--
Matthew Fuller (MF4839) | fullermd@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150714064212.GZ96394>