RFC: Pass TRIM through GELI

Steven Hartland killing at multiplay.co.uk
Mon Mar 16 11:55:26 UTC 2015



On 16/03/2015 11:52, Pawel Jakub Dawidek wrote:
> On Mon, Mar 16, 2015 at 10:14:42AM +0000, Steven Hartland wrote:
>> On 16/03/2015 09:21, Matthew D. Fuller wrote:
>>> On Mon, Mar 16, 2015 at 02:08:45AM +0100 I heard the voice of
>>> Pawel Jakub Dawidek, and lo! it spake thus:
>>>> Overall the patch looks good. The main concern I have is that we do
>>>> nothing if the underlying provider returns EOPNOTSUPP on BIO_DELETE,
>>>> we will just keep sending those requests.
>>> Well, they're all coming from the layer above us, and it'll get back
>>> the EOPNOTSUPP's, so if it keeps sending them anyway that seems more
>>> like its problem than ours.  It seems like intercepting the response
>>> (that would mean making our own new request, getting the response,
>>> then making that response ourselves to the original?) wouldn't really
>>> save much of anything, and adds a lot of extra bug-havens...
>>>
>> See how ZFS details with this, it adds internal state to the device
>> which stores and bypasses the pass down after the first EOPNOTSUPP.
>>
>> This avoids the full stack round trip, which when volumes of deletes are
>> high could be noticeable.
> By ZFS is at the top of the stack, GELI is just passing through the
> requests. I agree with Matt that ZFS is the one who should handle
> EOPNOTSUPP from the underlying provider, not GELI.
>
Ahh I see what he's saying now, thx.


More information about the freebsd-geom mailing list