Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 16 Mar 2015 10:14:42 +0000
From:      Steven Hartland <killing@multiplay.co.uk>
To:        freebsd-geom@freebsd.org
Subject:   Re: RFC: Pass TRIM through GELI
Message-ID:  <5506AD12.2090603@multiplay.co.uk>
In-Reply-To: <20150316092126.GC52331@over-yonder.net>
References:  <20150308000131.GP1742@over-yonder.net> <20150314151453.GJ24274@over-yonder.net> <501bca86.508d8e26@fabiankeil.de> <20150315145324.GA52331@over-yonder.net> <20150315182444.GB52331@over-yonder.net> <20150316010845.GA1515@garage.freebsd.pl> <20150316092126.GC52331@over-yonder.net>

next in thread | previous in thread | raw e-mail | index | archive | help

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.

     Regards
     Steve



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5506AD12.2090603>