From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Snitzer Subject: [PATCH v3 11/12] dm mpath: enable discard support Date: Mon, 26 Jul 2010 16:41:23 -0400 Message-ID: <20100726204123.GA20849@redhat.com> References: <1279987768-13275-1-git-send-email-snitzer@redhat.com> <1279987768-13275-12-git-send-email-snitzer@redhat.com> 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: <1279987768-13275-12-git-send-email-snitzer@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: dm-devel@redhat.com Cc: Kiyoshi Ueda List-Id: dm-devel.ids Enable discard support in the DM multipath target. This discard support depends on a few discard-specific fixes to the block layer's request stacking driver methods. Discard requests are optional so don't allow a failed discard to trigger path failures. If there is a real problem with a given path the barriers associated with the discard (either before or after the discard) will cause path failure. That said, unconditionally passing discard failures up the stack is not ideal. This must be fixed once DM has more information about the nature of the underlying storage failure. Signed-off-by: Mike Snitzer Cc: Kiyoshi Ueda --- drivers/md/dm-mpath.c | 10 ++++++++++ 1 file changed, 10 insertions(+) Index: linux-2.6-block/drivers/md/dm-mpath.c =================================================================== --- linux-2.6-block.orig/drivers/md/dm-mpath.c +++ linux-2.6-block/drivers/md/dm-mpath.c @@ -893,6 +893,7 @@ static int multipath_ctr(struct dm_targe } ti->num_flush_requests = 1; + ti->num_discard_requests = 1; return 0; @@ -1272,6 +1273,15 @@ static int do_end_io(struct multipath *m if (error == -EOPNOTSUPP) return error; + if (clone->cmd_flags & REQ_DISCARD) + /* + * Pass all discard request failures up. + * FIXME: only fail_path if the discard failed due to a + * transport problem. This requires precise understanding + * of the underlying failure (e.g. the SCSI sense). + */ + return error; + if (mpio->pgpath) fail_path(mpio->pgpath);