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>