Date: Sun, 08 Mar 2015 22:40:03 +0000 From: Steven Hartland <killing@multiplay.co.uk> To: "Matthew D. Fuller" <fullermd@over-yonder.net> Cc: freebsd-geom@freebsd.org Subject: Re: RFC: Pass TRIM through GELI Message-ID: <54FCCFC3.4000007@multiplay.co.uk> In-Reply-To: <20150308223552.GR1742@over-yonder.net> References: <20150308000131.GP1742@over-yonder.net> <54FC4E99.4080202@multiplay.co.uk> <20150308223552.GR1742@over-yonder.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08/03/2015 22:35, Matthew D. Fuller wrote:
> On Sun, Mar 08, 2015 at 01:28:57PM +0000 I heard the voice of
> Steven Hartland, and lo! it spake thus:
>> I don't see where your checking if the underlying device supports DELETE?
> From my understanding (which is hardly authoritative, to be sure, so
> I'm open to correction), I don't have to. GELI itself doesn't
> originate any BIO_DELETE's, so they're only coming from stuff on top
> of us. We just pass those through to what's underneath us and it does
> all the answering. If that doesn't support it, it would return an "I
> don't do that" response, which the filesystem (or whatever) on top of
> us handles[0] its way. So for _DELETE, as for _FLUSH and _GETATTR,
> GELI is just transparent.
>
> Am I mistaken?
>
Underlying BIO_DELETE support is optional, typically only supported by
SSD's via TRIM or UNMAP, so unless you check to see if the device
supports it you'll be translating delete so a noop, actually you'll be
forcing an extra layer to process the delete when it will never be able
to to.
Given GEIL is all about security translating the delete to a noop
results in a pretty serious security issue I would say as it will leave
data which he user intended to be removed present on the device.
Regards
Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54FCCFC3.4000007>