From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Snitzer Subject: Re: [PATCH 4/4] Support discard if at least one underlying device supports it Date: Fri, 2 Jul 2010 14:14:30 -0400 Message-ID: <20100702181430.GD26916@redhat.com> References: Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Mikulas Patocka Cc: dm-devel@redhat.com, Alasdair G Kergon List-Id: dm-devel.ids On Fri, Jul 02 2010 at 11:19am -0400, Mikulas Patocka wrote: > Support discard if at least one underlying device supports it > > The previous code was too restrictive. It required that every underlying > device supports discard to advertise discard support. > > If one of the underlying devices doesn't support discard and other does, > it makes still sense to advertise discard support and forward discards only > to the device that supports them. > > Signed-off-by: Mikulas Patocka As we discussed, we have a challenge where we need DM to avoid issuing a barrier before the discard IFF a target doesn't support the discard (which the barrier is paired with). My understanding is that blkdev_issue_discard() only cares if the discard was supported. Barrier is used just to decorate the discard (for correctness). So by returning -EOPNOTSUPP we're saying the discard isn't supported; we're not making any claims about the implict barrier, so best to avoid the barrier entirely. Otherwise we'll be issuing unnecessary barriers (and associated performance loss). So yet another TODO item... Anyway: Acked-by: Mike Snitzer